Re: Locks
Re: Locks
- Subject: Re: Locks
- From: Jean-Daniel Dupas <email@hidden>
- Date: Thu, 08 Dec 2011 10:34:21 +0100
Le 8 déc. 2011 à 09:57, Andreas Grosam a écrit :
>
> On Dec 7, 2011, at 12:07 PM, Jean-Daniel Dupas wrote:
>
>>
>> Le 7 déc. 2011 à 06:10, Ken Thomases a écrit :
>>
>>> On Dec 6, 2011, at 10:05 PM, Don Quixote de la Mancha wrote:
>>>
>>> You still shouldn't implement it manually using atomic increment and decrement. You should use OSSpinLock if that's what you're attempting. Which was my point. The original code was horrible and horribly misguided (and suffers from a race condition as others have pointed out, which is virtually inevitable when people try to reimplement synchronization instead of using ready-made synchronization primitives).
>>>
>>
>> A better solution would be to use posix mutex and completely avoid OSSpinLock.
>> There is really few situations where SpinLock give you any benefit, as mutex implementation already try to spin a couple of time before locking. So if there is no contention, they are both very cheap and fast, and if there is contention, the mutex is better as it don't consume CPU waiting for other threads.
>>
>> -- Jean-Daniel
>
> A possibly even better solution is to use dispatch semaphores. A non-recursive mutex can be build upon a semaphore. A pthread mutex always requires a call through the kernel. Dispatch semaphores require this only when the thread needs to be blocked. Otherwise, a spin lock is performed in user space.
> In the case of no contention, a dispatch semaphore is much faster than a pthread mutex. In case of contention, performance is comparable - but extreme contention should be avoided and considered a programmer error.
This is the same for pthread_mutex. They require a call though the kernel only if they have to wait and spin in user space if not. And they are more flexible (support recursive lock for example).
Of course, this additional flexibility has a cost, and locking/unlocking is 2 times slower with mutex, but they remain so fast that even in a tight loop, the difference is negligible.
The primitive you're talking about and that require a "syscall" (a mach message to be exact) is the mach_semaphore. It is almost 10 times slower than dispatch_semaphore.
> I've successfully used dispatch semaphores and variants to implement a mutex to synchronize access to resources.
>
>
> Well, and even yet another solution is to use dispatch queues, if possible. dispatch lib is open source and available on other platforms, too. But this would require to change the design.
>
>
>
> Andreas
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
-- Jean-Daniel
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >Locks (From: koko <email@hidden>) |
| | >Re: Locks (From: Conrad Shultz <email@hidden>) |
| | >Re: Locks (From: koko <email@hidden>) |
| | >Re: Locks (From: "Stephen J. Butler" <email@hidden>) |
| | >Re: Locks (From: Don Quixote de la Mancha <email@hidden>) |
| | >Re: Locks (From: Ken Thomases <email@hidden>) |
| | >Re: Locks (From: Jean-Daniel Dupas <email@hidden>) |
| | >Re: Locks (From: Andreas Grosam <email@hidden>) |