I need a way to wait in another thread for allegro's event queue to pop up with a timer event without disturbing the main thread but also at the same time being able to wake the main thread up if it receives an event.
Can anyone give me a simple walkthrough of how these things are done? Do I need allegro's threads, do I need mutexes (I'm guessing I probably do)?, do I need pthreads, or what? I think pthreads had something like a 'wait for signal' function but I can't remember what it was called now.
Anybody have some knowledge to share about these things?
I need a way to wait in another thread for allegro's event queue to pop up with a timer event without disturbing the main thread but also at the same time being able to wake the main thread up if it receives an event.
I was under the impression that's what the message loop did by default, as long as there was an al_wait_for_event() to cause it to idle when no events occurred. I assume you want the main thread to sleep, since you specify "wake the main thread up".
I think you might want to use 2 event queues, one for each thread.
If the main thread needs to be woken up by your second thread, let the second thread send a message on the main thread's queue and the main thread will wake up. The second thread can listen for events on its own without having to disturb the main thread.
Yup, just send messages back and forth.
Maybe I didn't explain well. I'm trying to implement my own event sources and I need the timer thread to sleep until the timer goes off, and then emit the timer event. As it is now I have to poll for the timer event in al_wait_for_event, but I want it asynchronous so I can just add the timer events to a message queue w/o disturbing the main thread.
That sounds less clear than your first question...
any thread can setup an event queue, and event sources, including timers. They can then wait on that queue.
Any thread can add events to a queue, which will only wake up other threads that are `al_wait_for_event`ing on that queue.
As it is now I have to poll for the timer event in al_wait_for_event
`al_wait_for_event` actually sleeps. It does not poll.
I'm trying to accomplish what allegro does with its event queues, that is it wakes up the thread when the signal goes off.
Maybe I have to post example code to show what I mean. I'm not at home though so can't post it atm.
I have a timer class. I am trying to decide whether to make it an eagle event source or to have my event handler subscribe allegro's timer event source to its queue. If I make my timer an event source then I need to emit an event whenever the timer goes off. That means I have to call al_wait_for_event (and use up one thread) to poll for the timer event using the private allegro event queue and timer. That's what I meant by polling.
So I want to create a thread that will call al_wait_for_event to wait for a timer. I want that thread to access an event queue and post messages to it, what I call an event handler. So do I need a mutex to protect the queue while I am asynchronously adding an event to it? Does allegro's event queues use mutexes?
Event queues are thread safe. You don't need to worry about locking around them afaik.
No, do I need a mutex for my eagle event queues, not for an allegro event queue.
I want one thread to wait on the timer, and then emit events whenever it goes off. However the event queue I want it to post messages to is on a different thread, hence the question about the mutex. I don't want to access the event queue at the same time I am adding an event to it. Do I need a mutex to keep my eagle event queues thread safe?
Oh, it depends on how you implemented your event queues. You can implement lockless queue algorithms, but I'm doubting you did so. so yes, you probably do want locking around access to your queue's internals.
There are also other locking primitives you could use, like condvars or semaphores.
Sounds a bit like you're reinventing the square wheel that is Allegro's event queue. Is there a reason that you can't just use Allegro's event queues as suggested?
Sounds a bit like you're reinventing the square wheel that is Allegro's event queue. Is there a reason that you can't just use Allegro's event queues as suggested?
I believe his library is supposed to support multiple back-ends and I think he doesn't want the core to have to rely on allegro.
Sounds a bit like you're reinventing the square wheel that is Allegro's event queue. Is there a reason that you can't just use Allegro's event queues as suggested?
Well actually yes I am a little bit. I just need mostly the same functionality with a small wrapper over it for abstraction and portabilities sake. I need my Timer class to be an event source but I don't want to poll for things. I want to post an event right away. Which means I need another thread to work alongside the main one, so I suppose I should wrap a Thread too. It's just adding another link in the chain of signals I guess. No biggie.
I believe his library is supposed to support multiple back-ends and I think he doesn't want the core to have to rely on allegro.
You are correct sir.
You can look up my latest code on sourceforge through svn :
svn checkout "svn://svn.code.sf.net/p/eagle5gui/code/trunk eagle5gui-code"
or just the url (click on copy link location)
svn://svn.code.sf.net/p/eagle5gui/code/trunk eagle5gui-code
It's building now and I'm working on tests to make sure everything works. Adventurous souls welcome, but the only docs I have are the headers.
There is a simple example program that displays your input and the frames per second. The build system is currently CB Projects, so you would have to adjust your linking and search directories to match whatever version of A5 you have installed.
I think what I need are semaphores.
I think what I need are semaphores.
AFAIK, semaphores might not work, what if each CPU has differing values in their respective caches? Of course, if you accessed this semaphore only through a mutex, it'd work.
What do you mean, semaphores might not work? They're not reliable ways to sleep and wake up a thread?
Forgot to post example code :
I'm wrong, Wikipedia says you're right. I was thinking you just meant ordinary booleans (like a semaphore flag, on a mailbox or a railroad crossing).
yeah, I meant a pthread semaphore.
I may just wrap Allegro's Thread routines. They seem solid enough to write a driver around.
Edit
Well, I did just that, and now I have a thread running my TimerProcess but everytime I run my test program, I get two assert failures that don't crash like they're supposed to, and the program keeps running in the background and doesn't return. In addition to that, there are two pointers that are null that should not be.
Allegro5Timer.cpp
I marked all the lines I thought were important. Does anybody see anything wrong with my logic? I make a new thread in Allegro5Timer::Create, make an allegro timer and queue, and make sure they're both valid and register the event sources and then and only then do I create and start the thread that runs TimerProcess, where I keep getting the two marked assertion failures that the timer and queue are both null. I don't get it.