Re: Threads and locks
Re: Threads and locks
- Subject: Re: Threads and locks
- From: Alastair Houghton <email@hidden>
- Date: Fri, 2 Apr 2004 11:59:38 +0100
On 2 Apr 2004, at 00:49, Chris Hanson wrote:
>
On Apr 1, 2004, at 3:25 PM, Mark's Studio wrote:
>
> i only use one NSLock is that enough, or do i need to have a seperate
>
> lock for every object?
You need to have a sufficient number of locks to prevent more than one
thread from calling non-thread-safe methods of any object in your
program. It's quite possible to use a single lock to control access to
*all* of the objects in your code, although that would usually be very
inefficient... in order to achieve good performance, you need to strike
a balance between having few locks (and therefore not taking advantage
of SMP machines to their full extent) and having too many locks (and
therefore spending a lot of time on the overheads of locking and
unlocking rather than actually doing the work your program is supposed
to be doing).
>
> what should i do to make this thread safe
>
> [array1 setArray:array2]
>
> both arrays are NSMutableArray
>
>
If you create your own NSLock, you'll need to pair it with the array
>
and always have a 1:1 correspondence between the NSLock object and the
>
object it controls access to. You'll also need to be sure to lock
>
when reading as well, since you don't want to be reading from it while
>
it's in an inconsistent state.
It's also worth mentioning that if you need to acquire multiple locks
in order to perform an operation, then it's best to always acquire the
necessary locks in the same order, because if you mix the ordering you
can easily end-up with a deadlock.
Kind regards,
Alastair.
--
http://www.alastairs-place.net
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.