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 13:21:14 +0200
On Monday, July 14, 2003, at 12:29 PM, Mark's Studio wrote:
>
>
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?
Alignment is determined by compiler options or pragmas. I think that
the default gcc alignment options are okay up to 32 bits integer but I
cannot remember where these pragmas are defined :-( 64 bits integer
looks to be default-aligned on 4 bytes boundary.
>
>
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
>
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.