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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
