Some threading bits

[Matias D'Ambrosio]

 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?
 Doesn't seem to be causing problems, but since you all seemed eager to see
some traffic... :-)

[killnow_thread.patch]

---

diff --git a/Alc/alsa.c b/Alc/alsa.c
index 95a1cf6..ea42b7f 100644
--- a/Alc/alsa.c
+++ b/Alc/alsa.c
@@ -40,7 +40,7 @@ typedef struct {
     ALvoid *buffer;
     ALsizei size;
 
-    int killNow;
+    volatile int killNow;
     ALvoid *thread;
 } alsa_data;
 

---

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

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..
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Matias D'Ambrosio]

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@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[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@...
http://opensource.creative.com/mailman/listinfo/openal-devel

  

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

On Thursday 10 July 2008 11:33:50 pm Killian De Volder wrote:
> 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.

That's likely true. In this case, though, all that happens is one thread
continually reads it, waiting for another to write/change it once. The
volatile is needed here to prevent GCC from assuming the variable never
changes since the thread reading it doesn't write to it.

> >  Anyway, a mutex should be used there if it's really important (can it
> > segfault? Or just causes noise?).

If a thread segfaults, it should take the whole process with it. The worst
that could happen is that it locks up/enters an infinite loop, in which case
a mutex won't do anything better.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel