Re: Releasing static variable & concurrent data protection questions...
Re: Releasing static variable & concurrent data protection questions...
- Subject: Re: Releasing static variable & concurrent data protection questions...
- From: Greg Guerin <email@hidden>
- Date: Mon, 15 Nov 2010 16:04:32 -0700
Frederick C. Lee wrote:
2) Static variables on stack <-- I was aware of this.
"Static" and "on stack" are mutually exclusive. It's impossible to
have a variable that is both, so "static variables on stack" is
nonsense.
BTW, the C storage specifier for "on stack" is "auto". You might
want to look at a C reference book and learn the difference between
the static and auto storage classes.
You can have a static pointer that points to a stack (auto)
location. This will invariably fail, and is simply wrong on any
semantic level. That's because auto lifetime is limited to a
function's lifetime; when the function returns all auto variables die.
You can have a stack pointer (i.e. auto pointer) that points to a
static location. There is nothing inherently wrong with this, unless
you're expecting thread-safety.
If you intend to perform concurrent calculations, I suggest read-only
inputs (sharable without locking), and single-writer outputs
(unshared, hence no locking needed). If the outputs must be
delivered to a common location, such as a queue, then that (i.e. the
queue) can be locked, but only for the duration of queueing the
results data. If you employ locking, you can quite easily lose any
concurrency gains by having contested locks. Then your threads are
spending all their time coordinating access, instead of doing work.
-- GG
_______________________________________________
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