Quote Originally Posted by ZoriaRPG View Post
Aye. Edgar Reynaldo over on allegro.cc is being just brilliant on this subject.

I went in expecting to get the old story of 'Just upgrade to Allegro 5', but instead I find that there is better support for ag4 now, than there was in 2011; so it would be prudent for each of us to participate on the forums there, and try to fix as much as possible in ag 4.4.3, and aim for a proper release of that.

Here is a [url=https://pastebin.com/JinsWu26]changelog for allegro 4.4.3 ]/url]over 4.4.2.

Insofar as they KB issue, I am having problems making the bug occur in any ZC build at present, including in 2.50.2. If it is a race condition as @Saffith suspects, then I am unsure how to trigger it. If it is a library issue as @Gleeok and I believe, then it may have been fixed--hard to tell just yet.

It would be great if all of our special needs, and out fixes, are simply in the core library though.

I have a few live topics over on allegro.cc if anyone wishes to participate in them.
The code snippet that Saffith posted on Pure is definitely buggy:
Code:
buffer->lock++;

   if (buffer->lock != 1) {
      buffer->lock--;
      return;
   }

   // Do stuff

   buffer->lock--;
C++ is not required to compile lock++ into an atomic operation, in which case the following sequence is possible:

Thread 1 reads the value of lock (0)
Thread 2 reads the value of locK (0)
Thread 1 post-increments lock (now 1) and enters the critical section
Thread 2 post-increments lock (writing 1 again) and enters the critical section
Both threads decrement lock (now -1).

As with all concurrency bugs, however, even though the code is objectively incorrect, it might happen to work on some compilers on some machines, where the increment happens to be atomic; or the bug might be present but never exercised due to precise timings of context switches on some particular machine.