| Re: [AD] Allegro on multi-processor machines |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Evert Glebbeek wrote:
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).
This happened to me once with the vram->vram accelerated blits using
DGA2 once. The image kept blitting, but I couldn't stop it. Except, not
only did the program become unresponsive, my entire system did as well.
When I wrote about it here before, I theorized it was because test's
timing loop doesn't rest (or even yield), so it was bringing up
XLOCK'ing problems.. like the lock was being released then acquired
again before the bg thread could get the opportunity to lock and read
input. Though I don't know if they should cause the entire system to
become unresponsive.
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.
That sounds like a mouse drawing related issue to me.
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.
The only BITMAP I could see possibly being made volatile is the screen
(and the backup memory bitmap with the screen). But AFAIK, even in
Windows, those are held in acquire/release calls which ultimately
translate to mutex's. Though of course, that does nothing for the mouse
drawing..
Is this also true of processors with HyperThreading?
Last I heard, HyperThreading was mostly just a marketing buzzword.
Processes still don't run in parellel. The only difference is that the
processor emulates two or more processors internally, instead of having
the OS do it. In fact, it could make properly optimized programs run
worse since an optimized program would be optimized for CPU instruction
timing and latency, but those optimizations break down when the CPU
allows another program to mix other instructions in with yours. There's
still only one L1/L2 cache set, and only one CPU core.
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.
The user would have to have such a version of pthreads, which would
create a dependancy. Besides, if we're doing something wrong with
threading, the best thing to do would be to fix it, not attempt to hide it.
- Kitty Cat