Re: NSFileManager - thread safety issues?
Re: NSFileManager - thread safety issues?
- Subject: Re: NSFileManager - thread safety issues?
- From: Chris Kane <email@hidden>
- Date: Fri, 24 Mar 2006 09:19:08 -0800
On Mar 21, 2006, at 8:57 AM, j o a r wrote:
On 21 mar 2006, at 17.37, Jim Correia wrote:
The documentation goes on to say "Some of these items may be made
thread-safe in the future but for now you should use a lock or the
@synchronized directive if there is a potential for access by
multiple threads."
This sounds like incorrect and bad advice to me. For example,
using NSFileManager inside a @synchronized block doesn't guarantee
that all code that I didn't write (system or third party
frameworks) will do the same, so it hasn't magically added thread
safety to that class.
I guess we would have to assume that Apple makes a promise here,
namely that their frameworks doesn't use improper locking when
accessing such shared functionality. I'm not sure if that's a safe
bet though.
I agree that the issue with third party frameworks is a pickle. As
long as Apple doesn't provide class & object level locks with
public accessors, that's probably rather difficult to deal with.
One way to solve it would be to document when something like this
is done in the framework, so that you could add your own locks on
these entry points.
Even if -lock and -unlock methods were provided in NSFileManager,
there's no guarantee that everybody would use them, particularly all
that pre-existing code out there.
Fortunately, that [new API from Apple] isn't necessary, as
@synchronized() makes every object its own lock. A typical pattern/
convention in other languages is to use the object you want to access
thread-safely as the lock. For example, if you have an array you
want to safely iterate:
@synchronized(array) {
for each element in array,
do operation
}
This is a handy convention for "where's the lock for this object?",
as other people will arrive at the same answer and there will be more
convergence on locking the same lock. It's also handy because
internal locking within the object cannot make all uses of the object
thread-safe.
HOWEVER (as I said above), there are still all those people already
out there now and in the future who will not do any locking when they
access the object, and it's debatable whether, say, 75% locking
coverage is better than nothing. So Apple has provided the class-
and object-level locks already, and it doesn't help. Internal
locking enforces the locking on client, but cannot make multiple
operations thread-safe.
But for objects you control in the scope of your code, that you want
to access in more than one of your threads, @sychronized on the
object in question (when there is a single obvious object) is a
useful pattern.
Chris Kane
Cocoa Frameworks, Apple
_______________________________________________
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