Re: Thread safety issue...
Re: Thread safety issue...
- Subject: Re: Thread safety issue...
- From: John Draper <email@hidden>
- Date: Wed, 05 Apr 2006 23:17:48 -0700
Craig Altenburg wrote:
It does not really matter which object is passed to @synchronized.
The idea is that only one thread of execution can be inside any of
the synchronized blocks that reference the same object.
Do you think my not doing this, is causing the hangup on my
mutex.lock(). With the understanding that
the threads are NOT Cocoa threads, but they do deploy a mutex.
The @synchronized statement has an object parameter so that you can
define blocks of code that DO NOT exclude each other.
I'm not sure I understand this....
Save for example you had a block of code that read something like this:
id objectOne = @"A";
id objectTwo = @"B";
@synchronized(objectOne)
{
<<some code. We'll call this block one.>>
}
.
.
@synchronized(objectTwo)
{
<< some code which we'll call block two.>>
}
.
.
@synchronized(objectTwo)
{
<< this is block three >>
}
Now, if two threads were to execute this code at about the same time
the system would keep both threads of execution from being in block
one at the same time. It would also keep both from being in either
of blocks two or three.
I notice that blocks 2 and 3 above are both using objectTwo. Is that
intentional?
But, since the blocks are synchronized on different objects, one
thread could be in block one while the other was in block two.
Similarly one thread could be in block one when the other was in
block three.
Note that passing an object in the synchronized does not, in itself,
keep both threads from accessing that object.
What happens? Does one thread wait?
As a matter of style, it is probably best to use the object that you
want to restrict access to as the parameter of the @synchronized
statement when you can, but this is in no way required.
So - if I think the threads are fighting over a NSMuteableArray
(receiveQueue), I would use that
object as the target of the Synchronize?
John
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden