[Openal-devel] Some threading bits

[Killian De Volder]

I did some reseach on threading for my sound lib.
(Note: I might be wrong !)
As I gained volatile is nowhere safe. (Unless you can guarantee the 
variable won't be accessed at the same time. Otherwiser)
volatile int v(8);
Thread A:
v++;
Thread B:
v--;

So lets look at what COULD happen
A: load V into register 1 (A.R1=8)
B: load V into register 1 (B.R1=8)
A: Increment register 1  (A.R1=9)
B: decrement register 1 (B.R1=7);
A: store register 1 into V (V=9);
B: store register 1 into V (V=7);

The expected outcome was 8 ....
Why does this happen even if it's volatile ?
Volatile only guarantees the int will be written to memory straight away 
/ without any optmalizations.
However, if 2 threads load the memory manipulate and safe it, there is 
no guarantee that the register will be in sync.

Solutions are:
Mutex / Semaphrores / or special cpu instructions (they allow cpu's to 
use the same variable safely together.)
> On Thursday 10 July 2008 22:13:56 Chris Robinson wrote:
>   
>> On Thursday 10 July 2008 11:13:12 am Matias D'Ambrosio wrote:
>>     
>>>  I'm attaching a ridiculously short patch which I'm not even sure is
>>> necessary. The variable killNow is an int (used as a boolean) in alsa.c ,
>>> apparently to stop alsa processing while killing the thread. Shouldn't it
>>> be a volatile?
>>>       
>> Is it legal to mark a single struct member as volatile, and not the whole
>> struct itself? You're right that it should be volatile because of the
>> threaded access, but I hope I don't have to make the whole struct volatile
>> to do it..
>>     
>  Yes, it's legal, though I didn't check the standard, and gcc didn't 
> complain... :)
>  Anyway, a mutex should be used there if it's really important (can it 
> segfault? Or just causes noise?).
> _______________________________________________
> Openal-devel mailing list
> Openal-devel at opensource.creative.com
> http://opensource.creative.com/mailman/listinfo/openal-devel
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://opensource.creative.com/pipermail/openal-devel/attachments/20080711/4c2ef360/attachment.html