First of all: My favorite method is a combination of [C] and [D] - that is, publish methods for manipulating the lock BUT call those methods from the property get/set methods as well. I like this combination because it allows me to easily read a single property when I need to and gives me the opportunity to "lock" the object longer if I need to read several properties in sequence.
About speed: Both TMultiReadSingleWriteSync and TCriticalSection are OS-provided services. A call to acquire/enter/leave/etc on any of those objects will actually generate a call on the OS and (I think) the OS will usually terminate your thread's "time slice". Even if that doesn't happen, there's some time penalty related to calling OS services on certain things. Also consider using the os-provided wait_xxx methods directly. Calling those methods directly allows you to specify a timeout value, so you can raise an exception if the lock can't be acquired in a reasonable amount of time. In one application I used a combination of calling wait_xxx methods directly + logging currently acquired locks to raise an exception saying: "entry-point XXXX did not release the lock in a reasonable amount of time" - that REALLY helps! "Busy wait": If time really is a problem, you may consider implementing a "busy wait" algorithm (also called a "spinlock" in the linux-kernel world). You'll find references to this algorithm using google. It essentially allows you to create a lock that can be acquired and released with no speed penalty at all as long as "race conditions" aren't common. __________________________________________________ Delphi-Talk mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi-talk
