Abstract event queue for GUI/model communication

Question

I hope this isn't so general a question as to be thought a "discussion." I'm writing a simulation of an old (ca. 1960) computer, and I'm thinking about how to queue events from the GUI to the CPU "model." The GUI consists of momentary-on buttons (pushbuttons and typewriter keys) and toggle switches. Of course, I don't want either the GUI or the CPU thread to block.

As I think about the various sorts of events, I realize that (a) some should not be replicated in the queue, (b) some should be "expedited" -- i.e., sent to the head of the queue, and (c) some should simply be ignored under certain conditions.

Then I realized that I'm probably trying to re-solve an old problem. Undoubtedly others have encountered similar requirements when trying to design a GUI-to-model event queue. So I wondered - has some brilliant person abstracted the requirements of any GUI-to-model event-passing system, perhaps anticipating some functionality I haven't even thought of yet?

I'm coding in Java, but I would be implementing the queue, and the queuing, myself - and furthermore, I doubt there's anything Java-specific to this problem.

Answer 1

How about using PriorityBlockingDequeue with put and poll?

• Despites its name it also offers a non-blocking way to queue prioritized events, which should solve (b).
• When it comes to (c), this is a little vague. What are those conditions?
  When should they be checked? Can you determine that before inserting them into the queue? Then don't insert them. Can you determine it after retrieving them? Then do it then. I can't really answer that any better without more specific constraints. I could only advise you to encapsulate both event data and the decision strategy within an event abstraction.

• As for (a), you should associate events with an eventtype (an enum might just do it) and for all non-duplicable eventtypes, use a HashMap to track their presence in the queue. You'll probably want to synchronize it, although it's not really necessary:

  1. Prior to inserting, check whether the eventtype is already marked as present. If it is, just drop the event. Otherwise:
  2. Mark the type as present.
  3. Insert the event.
  4. After polling the event, unmark its type.
  5. Process it.

  Since only one thread is inserting, it means you will not have duplication. What could happen is that an event is dropped, because the model-thread has just polled an event but not yet unmarked it, while the GUI thread attempts to enqueue one, so the check in step 1 will drop the event.
  However for one, the "old" event is technically not processed yet, so you could think of it as in the queue and secondly the "new" event would have been dropped anyway, if the model thread had polled just a little later.