Re: Locking and synchronization primitives
Brian Bergstrand wrote: Wally Crooze wrote:
A couple of more things on locking/synchronization primitives...
How effective are the implementations of funnels and other locking
mechanisms (e.g. simple_locks) for SMP systems? I noticed that
simple_lock is defined as either 1 (as funnels are in effect),
disable_preemption (on Uni-processors) or usimple_lock (on SMP
systems). I was under the impression that usimple_locks were for
uni-processor systems... this is confusing.
OS X is always in "SMP" mode, even on UNI machines. This is because the kernel is always compiled with pre-emption turned on. So simple locks will act the same as on SMP machines. I'm not sure I understand this statement. Pre-emption is a mechanism to allow multi-threading in a non-cooperative mode, I'm not sure how this effects multi-processors. I would hope that simple_locks and funnels enforce multi-processor safe locking. Are you saying that using the interface disable_preemption tells the other CPU to suspend their processing? Or is usimple_lock mechanism the correct interface to use? My problem is not simple. I am attempting to port a filesystem that uses many locking/synchronisation interfaces which aren't supported by darwin. I need interfaces which allow to check whether a lock is held and distinguish which thread is the owner. Also I need to be able to "try" to obtain a lock, which in the case that it returns if it can't immediately succeed, with a return value indicating this. In the case of an rwlock "try" upgrade (i.e. "read_to_write") it would return immediately, still retaining the read lock, if it couldn't obtain the write lock. On this note, I haven't found any interfaces which allow me to timeout when waiting, as "try" would have a timeout of 0. Any suggestions? Are these operations not supported for a reason? I also need the ability to retrieve the "value" of the semaphore. As part of this I would prefer not to write my own locking/synchronization primitives from scratch as many of them would require some "ml" coding. Can all of these be done through Wait Queues? Anything to prevent me from redoing everything from scratch and driving me insane would be greatly appreciated. Also, as my filesystem also communicates via BSD Sockets with other systems do I need to obtain the Network Funnel or is this done under the covers?
Also, can the locking and synchronization primitives be nested
safely?
i.e.
simple_lock(lock1)
simple_lock(lock2)
simple_unlock(lock2)
simple_unlock(lock1)
You can, but this kind of code can lead to deadlocks pretty easily. You have to be careful. Does the simple_lock mechanisms modify and restore the priority and interrupts correctly?
Does simple_locks disable interrupts, etc?
I can't remember if that is done for you, I always disable them manually when needed. What interface does this for you?
Also what interface is equivalent to synch-variables... such as
sv_init, sv_rmproc?
Can't help you there. Actually, a synch-variable is just a semaphore initialised to 0.
I'm also looking for a mechanism that will allow me to attempt to
upgrade (i.e. read to write) an mrlock, but if it can't get it
immediately it will return still holding the read (similar to the
try versions of the other locks).
Have you looked at lock__bsd__ in <sys/lock.h>? It is based around simple locks and supports read->write upgrades (I think). It may do what you need. No, I haven't, I suspect that this is only supported in BSD. The problem is that since I will have multiple threads, sometimes holding the funnel and other times not, I need a consistent locking/synchronization method which will work for both circumstances. -- Wally Crooze +-------------------------------------------------------+ | ,-_|\ Wally Crooze <wallycrooze@pobox.com> | | / \ | | \_,-._/ | | v | +-------------------------------------------------------+ _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.
participants (1)
-
Wally Crooze