Re: Thread Safety - A Theoretical Question
Re: Thread Safety - A Theoretical Question
- Subject: Re: Thread Safety - A Theoretical Question
- From: André Berg <email@hidden>
- Date: Tue, 13 Oct 2009 01:45:35 +0200
Huge thanks to everyone. Your time is valuable and I appreciate it that
you are spending it on helping me.
A lot of high quality, very useful answers.
I have decided to try and work towards the following pattern (in Mr.
Parker's nice words):
"One thread per instance. Much of Core Data works this way. A particular
instance may only be used from a single thread, but other threads may
simultaneously use other instances. The implementer made sure that any
global variables or shared data was thread-safe inside the
implementation, but per-instance data was not made thread-safe."
I will now try to answer Mr. Guerin's questions (to the best of my
knowledge):
"What do you mean by "real class"? Are the other classes you've
designed merely sham classes? Toy classes? Mock classes?
What other classes have you designed? And implemented?"
I guess with "real" I meant the first class I am designing on my own,
without outside help (help in the form of collegue, a book, a tutorial
or a workshop etc.).
It certainly feels "real" that way to me. While my class may not be
valuable to fulltime professionals, like you all are, I was still able
to use it very nicely to see how the following is done:
- memory management topics like using retain/release and using garbage
collection
- implement delegation
- conform to various protocols, like NSCoding or NSCopying
- write extensive header documentation and use doxygen to make a docset
out of it
- write unit tests
- use DTrace and Instruments to gain a better picture with use of custom
probes and dtrace scripts
- use the ObjectGraph, ObjectAlloc and Leaks instruments
- others... (I don't want to bore you :))
I have been working on this for the past few weeks on my sparetime...
time which includes reading all the different companion guides on
various subjects.
On a side note I find the Apple documentation to be excellent. I may not
understand it all fully but that's why I am doing this.
I guess you won't get far as a Cocoa dev if you haven't been facing a
lot of the decisions that go into designing a class. You will never get
far in programming without doing, in general.
"In what circumstances is this real class going to be used? Are you
designing it for your own use or for others? "
Currently for my own use but I may open source it. My plan is to extend
an Open Source application with a plugin and use the class there. If all
goes well and it proves useful I will host it somewhere.
"You're using readInBackgroundAndNotify, which implies a run-loop for
correct operation, IIRC. Is that fact documented for your class? Will
the class work properly in a run-loop in a non-main thread?"
From my own research on NSTask (a lot has been written) "Yes" to the
first two questions. As I am just now tackling the threading issues I
can't answer the last question with full certainty yet (it should work
but I'd rather test).
"What is the NSTask doing? Is the use of NSTask apparent to users of
the class?"
At the heart my class is mainly a decorator to NSTask and this fact is
mirrored in the documentation, so I would say so, yes.
"Is it necessary for users to know this (other than the dependence on
run-loop necessitated by readInBackgroundAndNotify)?"
From my point of view, it shouldn't be necessary to go into much more
of the internals than mentioning the run-loop dependance.
Again, thanks alot everyone for your input.
Cheers,
André
_______________________________________________
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