Re: [AD] Allegro on multi-processor machines

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On Wednesday 01 September 2004 15:32, Peter Wang wrote:
> AFAIK, without proper thread synchronisation, two caches may have 
> different ideas about the contents of the same memory address, e.g. one 
> thread updates a global variable X, but the other thread still sees the 
> old value for X.  I read that Allegro's mouse would "stall" on 
> multiprocessor machines (before the program crashed, that is :-).  This 
> could be one explanation.  I just saw that mouse_x,y are marked 
> volatile, but not the internal variables _mouse_x,y.

I think you're on to something there... I tried changing a bunch of 
variables from mouse.c and xwin.c to volatile and the nature of the crash 
changed: if I could start the timed putpixel from the test program, the 
program would become unresponsive to all forms of input, but the pupixel 
loop would continue indefinitely (but the count isn't shown).
The program still freezes though, and not always in a predictable way. I've 
seen it freeze in the middle of drawing a pull-down menu, for instance.

I'm not sure I have time to investigate much over the next few days --- 
afterall, I don't get paid for debugging Allegro ;) --- but I'll try to 
look into this a bit more. One thing that does worry me is that to fix the 
problem some of the BITMAPs may need to be made volatile, although we 
could probably block on a mutex instead.

> Also, on a single processor machine threads never *really* run in 
> parallel.  I think Allegro can get away with a lot more dodgy practices 
> then.

Is this also true of processors with HyperThreading?

I'll also see if there's a way to tell the linker to link to a version of 
pthreads that doesn't distribute threads over multiple processors. That 
should also fix the problem as a quick work-around.

Evert