Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Not thread safe events?



On Oct 20, 2005, at 7:51 AM, Mike Kluev wrote:
"Object"? The related concept in Carbon Events is event target and
being the "upper half" concept it is not thread safe. Carbon event
constants themselves can't be thread safe or not safe (they are
just integers). If you wish to treat them as "methods" you surely
can, but then, the only relevant APIs are PostEventToQueue and
SendEventToEventTarget; this is the "send" that can be treated
as "method invocation" (the "post" doesn't invoke anything itself)
and "send" it is not thread safe no matter what "object" you are
talking to and what event you are sending it (what method you call).
Dead end.

I said "object" because I'm talking about abstractions. I am not talking necessarily about any concrete technology or even any specific platform. My point was that it does make sense to talk about objects themselves as being thread-safe in addition to the calls that work with them. I do primarily work with Cocoa, but thread safety really is an issue that transcends frameworks and platforms.


To use Carbon Events as an example, there is an "object" concept in Carbon Events beyond the event target -- the Carbon Events themselves. A Carbon Event is represented by an EventRef that can contain a fairly open set of parameters etc. To say that an EventRef is not thread-safe means by default that you cannot manipulate an individual EventRef from multiple threads at once using APIs like SetEventParameter.

When an API is documented as not being thread-safe, that means you can't call that API from multiple threads at once -- whether on the same object or on another object -- unless there's clarifying documentation.

For example, let's say for the sake of argument that SetFooParameter is documented as being thread-safe but FooRef objects are documented as not being thread-safe. That means you can call SetFooParameter safely from multiple threads without locking but that you can't call SetFooParameter on the same FooRef from multiple threads at once, period, even with locking. (After all, you may not own all the code paths that would need to have locking added to make doing so thread- safe.)

Thread safety is a tricky issue, especially in its interactions with API design (not to mention API implementation). It's important to understand exactly what the implications for both data and for code are when you're doing multithreaded development, particularly as more CPUs are added to the mix. You can actually build systems that look like they work correctly on one CPU, look like they work correctly on two CPUs, and then demonstrate that they're not actually correct when more CPUs are added.

  -- Chris

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden

This email sent to email@hidden
References: 
 >Re: Not thread safe events? (From: Mike Kluev <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.