Re: Cocoa, Threads and Callbacks
Re: Cocoa, Threads and Callbacks
- Subject: Re: Cocoa, Threads and Callbacks
- From: Philippe Wicker <email@hidden>
- Date: Mon, 14 Jul 2003 11:07:19 +0200
On Sunday, July 13, 2003, at 11:24 PM, Mark's Studio wrote:
I'm still experimenting, adding more and more different widgets.
XYScope, peakmeters, etc. just to see how it works.
I have a soundPlayer object, that has the callBack that feeds data to
the defaultOutput,
within the callBack i send NSNotifications with position info, at
various intervals to other objects to update there UI.
and it's beginnig to be a bit crowded.
I was thinking of implementing it in another way.
When the soundPlayer starts playing,
Start a thread for every widget, and then access the position info from
the soundPlayer,from the thread at certain intervals.
if i have something like this in the soundPlayer
-(int)positionInfo{
return positionInfo;
}
it's only the soundPlayer that updates the positionInfo (in the
callback),
do i then need to use a NSLock when updating the positionInfo?
No need to use a NSLock (or a CAGuard or a mutex for non Cocoa guys).
As long as your data is a "native" type (eg 32bit integer) and that the
access to that data may be executed in one access cycle it will be
okay. If your "native" data is unaligned (eg a 32bit integer at an odd
address) then read/write may need 2 cycles, the atomicity is then a
hardware design issue and may or may not be guaranteed.
can i just call [soundPlayer positionInfo] from the other threads?
Yes. Just in case, never access the data more than once in a block of
code. Instead do a local copy and do your work on that local copy.
Is accessing a immutable object always thread safe?
Maybe I've misunderstood your question here, if so, I apologize
beforehand. Read access to a piece of memory which is never modified is
always thread safe.
Will this work, and is it the right way to do it?
Using a lock (NSLock, CAGuard, pthread_mutex,...) is only necessary
when you cannot guarantee by some other mean the atomicity of the
access to your shared data by consumer(s) (read access) and producer(s)
access(es) (write access).
I know of two techniques that can be used (there may be more, if
someone has another idea, please let us know):
- using data that can be read or write in one access cycle (such as
your positionInfo),
- using atomic APIs. It is possible, using "try and retry if failed"
strategies, to implement atomic add, sub, queue, dequeue, ... without
locks (have a look to Alberto Ricci "Atomic operations" posting and the
warning posted by Kelly Jacklin on that topic. You may also download
the Darwin kernel sources (called xnu) and look for these atomic APIs
inside).
Peter Mark
Mark's Recording Studio A/S
Lundeskovsvej 3 2900 Hellerup
Denmark
Tel: +45 35366078 Fax: +45 35366038
www.marks-studio.dk
email@hidden
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
Philippe Wicker
email@hidden
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.