Re: locking editing context
Re: locking editing context
- Subject: Re: locking editing context
- From: Art Isbell <email@hidden>
- Date: Tue, 11 Feb 2003 11:30:03 -1000
On Tuesday, February 11, 2003, at 07:30 AM, Jonathan Rochkind wrote:
At 05:33 PM 2/10/2003 -1000, Art Isbell wrote:
Locking isn't necessary unless you are writing a
multithreaded app.
Writing and debugging a multithreaded app is so difficult that it
should be avoided unless you really have no choice.
This is not what others have told us in the past. We have been told
that ALL apps are multithreaded---even if you don't turn on
'concurrent request handling', there will be multiple threads, and
it's possible that two of them could be accessing an EO at once.
All apps in which the worker thread count is greater than 0 are
multithreaded in that several worker threads are started by WO to
monitor the port which receives requests from the Web server. But
these threads don't access your custom code concurrently unless you
enable concurrent request handling. At least, that's the way I
understand it.
I avoid attempting to write thread-safe code and enabling concurrent
request handling. I have never experienced the sort of bugs and
crashes common with code that's multithreaded yet not thread-safe, so
I'm pretty confident that my code is never executed concurrently by
multiple threads.
The example frequently given was posting and handling of notifications.
I have never seen anything that suggests that notifications are
handled in anything other than the main thread.
But this is always controversial---some people insist adamantly that
if your app does not have concurrent request handling turned on,
there's no way for two threads to be accessing the same EOF stack
objects at once.
I agree.
Others insist just as adamantly that this isn't true, and you still
need to worry about locking.
Nope.
Myself, I have no idea. I do know that: it seems fairly certain that
you don't need to worry about locking the
session().defaultEditingContext() yourself in usual circumstances. The
WO framework takes care of it for you. I also use nested editing
contexts. I have not found a reasonable design pattern to lock these
nested ECs when neccesary in a way that is reliable and does not
result in deadlock, and in a way that doesn't make my code
unacceptably complex. So I have not been locking them---even though
I'm not sure if I'm supposed to or not. My app does not have
concurrent request handling turned on.
You should be fine without any locking. I have read that even with
concurrent request handling enabled, the session's default editing
context need not be locked by the programmer. And several shared
editing context methods are documented to be thread-safe without
locking (but others aren't). Apparently editing contexts created by
the programmer must be locked/unlocked by the programmer when
concurrent request handling is enabled.
Art
http://homepage.mac.com/aisbell/
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.