Re: NSOutlineView threading problem
Re: NSOutlineView threading problem
- Subject: Re: NSOutlineView threading problem
- From: David <email@hidden>
- Date: Mon, 16 Jun 2008 10:47:36 -0400
On Mon, Jun 16, 2008 at 1:25 AM, Michael Ash <email@hidden> wrote:
>
> I'm not sure how having thread safe arrays would help. If you're
> mutating a collection in one thread while you're accessing it from
> another then you will have trouble no matter what happens.
>
> Take this example. The outline view asks you how many items there are.
> You say 3. Now your background thread deletes one. Now your outline
> view asks you for item #3. Your code explodes violently.
Seriously? Folks are so scared of threading can't even imagine how it might
work.
No Java won't explode in that scenario with a Vector. In that scenario, when
the second thread goes to retrieve the item that is no longer there, it
behaves predictably, as documented. In this scenario the vector no longer
has item #3, it throws an ArrayIndexOutOfBoundsException. Your code then
needs to deal with this, but it doesn't "explode".
>
>
> Handling this properly really requires a whole new API. You need a
> concept of transactions, or views on the data, or explicit locking of
> the data structures. Simply making NSMutableArray thread safe gives
> you essentially nothing, it just moves the problem around.
>
> Essentially thats what making it thread safe does... lock critical data
structures. So in the vector example, methods are synchronized so that
critical internal structures can't be modified and read at the same time. It
can be argued that you can accomplish the same thing externally in the
developers code, but it leads to wild fears as mentioned earlier in this
thread that no amount of locking can protect you from using non-thread safe
classes in Cocoa. That fear should be alleviated with better descriptions
from Apple of what is necessary to make their classes thread safe or by
providing some option on the classes to enable thread safe behavior.
If the argument against basic thread safety is performance... then make it
an option.
If the argument is that thread safety requires higher level semantics, such
as transactions which can only be implemented in the application... then
Apple should do a better job documenting how to make them tread safe so that
people don't imagine wild scenarios which locking cannot protect against.
Writing code which effectively uses threads in a safe manner is clearly more
complex and requires careful thinking. But at least in Java you can predict
behavior because thread safe classes are available, and because the source
is available to remove any ambiguity on what might actually be taking place.
Apple's lack of source, lack of documentation and providing too few or too
restrictive guidelines makes it more dangerous in the Cocoa world that it
should be.
_______________________________________________
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