Date: Fri, 13 Dec 1996 14:51:48 -0500 From: Bakul Shah <bakul@plexuscom.com> To: Peter Dufault <dufault@hda.com> Cc: michaelh@cet.co.jp, Hackers@freebsd.org Subject: Re: Implementing atomic DCAS on Intel for NBS Message-ID: <199612131951.OAA19205@chai.plexuscom.com> In-Reply-To: Your message of "Fri, 13 Dec 1996 05:51:44 EST." <199612131051.FAA12751@hda.hda.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> That one shared lock will get pretty busy, while with standard > locking the lock activity can "page" to a point in an MP hierarchy > where they are actually used. I'll have to look up the references > to see how this locality issue is discussed. True. There is an implementation that avoids a shared lock but it is messy (not inefficient, just messy). Follow a link on http://www.cs.unc.edu/~anderson/papers.html) to `A framework for implementing objects and scheduling tasks in lock-free reak-time systems' by Anderson & Ramamoorthy. Given that DCAS is used in a specific way (the first value changed is always the version number), a simpler solution may be possible. > Language support with some kind of commit operation on data structures > seems attractive - by this I mean only declaring those parts of a > data structure that must be lockable lockable, and automatically > getting write accesses nCAS'd where the system would update all > fields at once from a temporary (together with the serial number > update - go easy on this - I haven't thought about it much yet). You seem to be looking for `atomic transactions' so that all the changes occur or none. All writes bracketed by begin transaction ... end transaction are written to a `log' and these changes are commited (or aborted) at the end. Obviously, commits are done by using nCAS. Within the transaction each thread/process wants to see their own changes as if they are already commited but not any other thread's -- if the compiler does the bookkeeping of whether you should get the value of foo->bar from &foo->bar or the temp place, the code logic remains uncluttered with such low level details. On the other hand I wouldn't hold my breath on any compiler providing support for this. You may wish to read `Nested Transactions' by J. Elliot B. Moss (MIT press, 1985). But we are getting away from any FreeBSD relevance! -- bakul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612131951.OAA19205>