Difference between event queue and message queue

Question

I was just seeing the documentation of three methods which can be used to execute a piece of code in the UI thread while we are working in a worker thread. The methods are:

1. public final void runOnUIThread(Runnable action) - Runs the specified action on the UI thread. If the current thread is the UI thread, then the action is executed immediately. If the current thread is not the UI thread, the action is posted to the event queue of the UI thread

2. public boolean post(Runnable action) - Causes the Runnable to be added to the message queue. The runnable will be run on the user interface thread.

3. public boolean postDelayed(Runnable action, long delayMillis) - Causes the Runnable to be added to the message queue, to be run after the specified amount of time elapses. The runnable will be run on the user interface thread.

The first one posts the Runnable to the event queue of the UI thread, while the other two add the Runnable to the message queue. Please tell me the difference between the two?

My web search tell me that an event queue is simply a queue of events waiting to be executed by the thread. I am not clear about the message queue. MessageQueue is some class as well, is this related to that?

Thank you in advance.

Answer 1

I think the two are synonymous. Events are indicated to the system using messages.

The real difference between the two methods is that one appends it to the queue immediately while the other delays it by the specified amount.

EDIT: More on messages

Messages are a way of communication between independent threads. In a way, it's a lot like the communication that takes place when you pull up a website in your browser: You send a message to the server detailing what exactly it is you want (GET www.stackoverflow.com, I will accept the following character encoding, do not track me, blablabla), which makes the server as the recipient of the message do something (retrieve content from the database, render the page, etc) and communicate the results of this back to you via a message.

How it works is like this: The thread has a Looper attached to it. All it does is run forever in a continuous loop, on each iteration checking whether there are any messages in its message queue. If there aren't, it goes to the next cycle. If there are, it retrieves the first message to deal with it.

However, the looper itself doesn't know what any of the messages mean - it's just there for looping. Neither does the thread, which just provides the infrastructure for the looper to run in. What the looper does know, however, is who to go to for handling the message: One of its Handlers. It passes the message to the handler, which can now go and do whatever it is that it needs to do to handle the message.

Answer 2

A message queue and an event queue are very similar design patterns with one notable difference.

First off let's review the similarities. Both are asynchronous. They store notifications in FIFO order. Sending a notification enqueues the event/message and returns.

Later on the EventManager/MessageManager will dispatch all those Events/Messages to the recipient objects. The difference lies in that with MessageQueues it's typical that the sender requires a response. With an EventQueue this is not necessary.

So message managing gives more control to the sender of the message. With an event queue all the sender can do is throw a request in the queue and hope for the best. That additional control provided by a MessageQueue comes with a small complexity penalty.

Choose the simplest data structure that you need for the job.

Answer 3

Just to make things clear : UI thread and user interface thread are the same thread and the event queue and message queue is the same queue.

The common point between runOnUIThread and post is that both cause the Runnable to be executed on the UI thread.

The difference between the two, is that runOnUIThread runs the Runnable immediately when it is called from the UI Thread while for post, a message is always posted, causing it to be run after other messages.

The simple answer to "which one to use" would be to use post if you don't know because if runOnUIThread is called with a Runnable that does runOnUIThread(this), it will lock the UI thread and lead to a stack overflow.

Source for the answer : code from Activity source code found in this page :

public final void runOnUiThread(Runnable action) {
  if (Thread.currentThread() != mUiThread) {
    mHandler.post(action);
  } else {
    action.run();
  }
}

Answer 4

As others have already pointed out, the event queue and the message queue are the same in your case. However, generally speaking, there is a difference.

They have the queue in common (as the names tell): a data structure where you put and get elements in FIFO order.

Now the difference is, whether you put messages or events in that queue.

What's the difference between messages and events?

A message

• has a clear, addressable recipient
• is usually sent with the intention to let the recipient know or make him do something ("Do xyz!")
• can be synchronous or asynchrnous

An event

• has no recipient, is just put in some place (where others can listen and maybe react to it)
• is a pure statement that something happened, with no intention of notifying anyone. The producer doesn't care who listens to those events and he doesn't need to know. ("xyz happened.")
• is always ansychronous

More on messages vs. events and Event-Driven Architecture: The Many Meanings of Event-Driven Architecture • Martin Fowler • GOTO Conference 2017 (YouTube).

What's the difference between message queues and event queues?

The third points from the previously made distinction between messages and events (synchronous/asynchronous) cannot help us here. Having a queue between two components always means the communication is asychronous (there's no waiting for one another, it's decoupled!). But the first two can.

• if the elements in your queue have a clear recipient -> it's a message queue
• if the elements in your queue are sent with the intention to make that recipient do something -> it's a message queue
• else -> it's an event queue

Is your queue a message queue or an event queue?

Your queue is definitely a message queue.

You can tell that from the definitions of messages and events in the previous section.

First of all, because those elements have a clear recipient: the UI Thread. That recipient even owns the queue, as the phrasing gives away:

If the current thread is not the UI thread, the action is posted to the event queue of the UI thread.

And secondly, those elements are sent with the intention to make the UI Thread do something - they are literally saying "Execute this action!"

The documentation writers must've just been sloppy with the phrasing here.