If one is interested in running the program in DOS, then the app must be coded in a special way so as that DOS is handled appropriately.

It is not very difficult to use #ifdef to include different APIs according to platform.

Yes. It would make the program correct in those platforms that input is handled by a different thread.

Allegro has many DOSisms. Any modern library would not use the concept of interrupt to service input, but the concept of input queue. Unfortunately for us, Allegro does not do that, so there are two solutions:

1) fix Allegro to provide a mouse queue, like the keyboard queue.
2) use callbacks to implement your own queues.

I have done #2 in my GUI code.

It's minimal, because critical sections are used.

Nope, you got it wrong here. The lock will not synchronize the input threads, because there is only one input thread. The lock will synchronize the input thread and the main thread.

Exactly.

It's no big deal to do so; just a couple of #ifdefs.

The cost of debugging multithreaded programs far outweights the cost of installing and linking with a library.

Here is a very interesting link with the following quote:

No variable or structure should be accessed from multiple threads without being accessed in a thread-safe fashion.

Obviously the guy has great experience with threads and Windows, so if you don't accept my comment, please accept his.

The only 'coded properly' technique with multiple threads is to use synchronization. Didn't you read the link I posted?

1. http://moss.csc.ncsu.edu/~mueller/pthreads/
2. I don't consider copying input to a buffer "clever". It's basically the ONLY thing that the input callbacks are useful for.
3. edited: hm... It won't work correctly on platforms with sufficiently weak memory coherency models. Investigating...

You conspicuously omitted the next line "Note that this applies only to variables where concurrent access can produce incorrect results". He then links to an example of his where he recommends using just volatile variables.
You might think that your position is vindicated by his next statement that incrementing a volatile integer is not thread-safe on a multi-CPU system. However that statement does not apply to the special case where only one thread modifies a variable (while other thread(s) read it).

There are three different locking scenarios we're looking at here in this thread:
locking type A: input callbacks lock to prevent reentry into the input callbacks
locking type B: input callbacks lock and input reader lock (same lock), to prevent reader from reading not-yet-ready events
locking type C: input readers lock (in a program with multiple threads, not counting those allegro created)

In that particular case, you were apparently talking about type B, while I was talking about type A. It is my position that locking types A and B are pointless. I think everyone is in agreement that type C is necessary if and only if the program is multithreaded (not counting Allegro-created threads that the user code knows nothing about).

However, I'm beginning to suspect that you might be right. After reading through a bunch of x86, PPC, and C docs, it looks like the ordering may not be guaranteed between multiple CPUs under the circumstances in which the callbacks execute on various platforms unless extra effort is made. That's somewhat scary though, as this appears to be what Allegro does internally... possibly I've been up to long, but to my current interpretation, not only is this code slightly flawed in a multi-CPU environment, but so is Allegro keyboard handling on WIN32 and OSX. And I'm not too sure about the Linux version either... executing in the SIGIO handler protects it somewhat, but only if the reading thread is the original thread, and it can also execute in a timer callback instead, or from the main thread if simulate_keypress is called...

Will think more tomorrow. Hopefully.

edit: fixed typo and changed #3 at the top

You seem to be ignoring the point of that: when a variable is only written to by one thread, the atomicity of the entire read-modify-write operation becomes irrelevant. Only the atomicity of the write operation itself is relevant, because the variable cannot be modified asynchronously to that code (because only one thread modifies it). And the write is generally atomic, provided that the integer is aligned (caveats: not true on 386sx when paired with a 32 bit compiler, some 8 bit CPU/compiler combinations, a few other arcane places... but to get even a remotely possible failure you have to find a platform that uses one of the handful of CPUs on which that's not true, uses multiple CPUs concurrently, and runs Allegro programs; you'd have an easier time finding a system that uses 10 bit bytes).

That is the part I'm agreeing with now - that using the variable as an index into a changing buffer is unsafe. According to my current understanding, this code has the capacity to return garbage input (though it almost never will). It could be fixed with threading libraries, platform specific locking mechanisms, or more exotic coding methods. However, I think that the Allegro internals have the same flaw in them, so you suffer from this flaw regardless...

I remembered the multicore part, but did not realize that Intel and others had weakened their memory coherency policies (I expected at least PRAM consistency for writes to volatile variables). And I presumed that Allegro would arrange things in such a way that its input callbacks were usable in a safe manner without extra dependencies or extraordinary effort.

edit:

ARRGHH!
Okay, I was too tired when coming to the conclusion that it wasn't safe. x86 DOES still offer strong memory coherency, I misread the docs as saying the opposite of what they said. Here's my current position (hopefully I will slow down the rate at which I change positions soon):

The code is correct on some platforms only.
Allegro code is correct on some platforms only.
Which platforms?

x86/*: Allegro and this code both work, because of strong memory coherency guarantees on normal x86 systems.

non-x86/linux: Allegro and this code probably work correctly, if the user code is totally single-threaded. Merely having only one thread talk to allegro is not enough though - it must also be the thread that handles signals. On x86 specifically the issue is (I think) irrelevant though because of the x86/* strong coherency guarantees. However, the buf.lock mechanism should be kept, because in (very rare) cases the callback can become reentrant.

PPC/macOSX: Allegro and this code are both incorrect on this platform.

PPC/macOS9 and x86/DOS: Allegro and this code are correct, because (I think) the code all executes in interrupt context anyway.

And to submit a bug report : )

http://www.allegro.cc/forums/thread/590120