Re: Cocoa, Threads and Callbacks
Re: Cocoa, Threads and Callbacks
- Subject: Re: Cocoa, Threads and Callbacks
- From: "Mark's Studio" <email@hidden>
- Date: Mon, 14 Jul 2003 12:29:37 +0200
On mandag 14. juli 2003, at 11:07, Philippe Wicker wrote:
>
>
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.
it's a instance variable
UInt32 positionInfo;
declared in the @interface
is that aligned?
there is actually some calculation, is that making any difference?
-(int)positionInfo{
return positionInfo + someLocalVariable;
}
I've already tried with one thread and it seems to work so far.
what happens if a thread try to read the positionInfo, while the
soundPlayer is updating the info?
>
>
>
>
> 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
>
>
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.