Re: Locks
Re: Locks
- Subject: Re: Locks
- From: "Stephen J. Butler" <email@hidden>
- Date: Tue, 06 Dec 2011 21:24:37 -0600
On Tue, Dec 6, 2011 at 9:07 PM, koko <email@hidden> wrote:
> I did come across OSAtomicIncrementXX … thanks.
>
> I cannot use NSLock as this is in a BSD Static lib and I am required to implement as close to windows as possible.
>
> So my code looks like below and is isomorphic to the Windows implementation.
This code doesn't work.
> =========
> LONG volatile Mylock = 0;
>
> void SetLock()
> {
> while(Mylock){Sleep(0);}; // Give up timeslice
> #ifndef MAC
> InterlockedIncrement(&Mylock);
> #else
> OSAtomicIncrement32(&Mylock);
> #endif
> }
There is a race condition between your test and set/increment
operations. If two threads are spinning on the same variable then they
could both see 0 at the same time, and your Mylock ends up with 2.
You probably didn't see this race condition on Windows because you
entered a critical section. Which begs the question, if you remain
inside the critical section the entire time you're locked, what's the
point of doing the spinning? Only one person can be inside a critical
section at one time anyway.
I'm guessing someone added the critical sections because they ran into
this race condition and didn't understand enough about multithreaded
programing to fix it.
On OS X you want to spin on the return value
OSAtomicCompareAndSwap32(0, 1, &Mylock).
Actually, what you really want is to rewrite this code using proper
mutexes. Spin locking is only acceptable in highly, highly critical
paths and when you don't expect the lock to be held for more than a
couple instructions. Otherwise it's damn unfriendly.
> void FreeLock()
> {
> #ifndef MAC
> OSInterlockedDecrement(&Mylock);
> #else
> OSAtomicDecrement32(&Mylock);
> #endif
> }
> ===========
>
>
>
>
>
> Thanks.
>
> -koko
>
>
>
> On Dec 6, 2011, at 5:39 PM, Conrad Shultz wrote:
>
>> On 12/6/11 3:28 PM, koko wrote:
>>> In windows we have:
>>>
>>> LONG volatile Mylock = 0;
>>> InterlockedIncrement(&Mylock);
>>> InterlockedDecrement(&Mylock);
>>>
>>>
>>> What should these be replaced with for OSX as in :
>>
>> Have you read the Threading Programming Guide?
>>
>> I'm not a Windows developer, so I had to look up the MSDN docs, and
>> based on those it seems like you want the OSAtomicIncrementxxx (and
>> matching OSAtomicDecrementxxx) as direct analogues.
>>
>> However, since it sounds like you are trying to use these functions to
>> implement locking in a multithreaded application, perhaps you should
>> also examine whether higher level constructs would prove sufficient. A
>> couple such mechanisms you can read about are NSLock and the
>> @synchronized directive. GCD has some features (dispatch semaphores and
>> barrier blocks come to mind) that may also be helpful in certain
>> circumstances.
>>
>> --
>> Conrad Shultz
>>
>> Synthetiq Solutions
>> www.synthetiqsolutions.com
>>
>
> _______________________________________________
>
> 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
_______________________________________________
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
- Follow-Ups:
- Re: Locks
- From: Don Quixote de la Mancha <email@hidden>
| References: | |
| | >Locks (From: koko <email@hidden>) |
| | >Re: Locks (From: Conrad Shultz <email@hidden>) |
| | >Re: Locks (From: koko <email@hidden>) |