Queued methods feature

Queued Methods feature

In some contexts it is desirable for a thread to request a potentially delay-prone task to be initiated in a separate thread so that the original thread can continue its work.

One context for this would be sending of messages. The message-sending process could take a lot of time, especially if we are using the 'distributed' mechanism of Java with RMI, which is natively synchronous.

A proposed solution is to allow any void method to be declared 'queued', meaning that its call is put in a queue, in a similar manner to the way calls coming into a queued state machine are put in a queue. A thread is then used to process methods from the queue in FIFO order.

All methods declared 'queued' in a class would share the same queue (per instance), ensuring order of operations of methods is preserved. The queue and queue-processing thread would be created on instantiation of an object if there are any queued methods in the class.

As with queued state machines, the method that actually executes when processed by the queue would have an underscore prepended, so for example a call to 'queued m1()' would result in execution of '_m1()'.

As with queued state machines, it will be necessary to interrupt the queue-processing thread (potentially cancelling still-in-process method calls) upon object deletion.

Syntax changes

The only syntax addition would be to allow specifying the keyword 'queued' before a void method. The word void could be omitted and would be assumed. An error would need to be raised on an attempt to specify 'queued' before a non-void method.

Potential unintended consequences

In certain situations, races could result. For example if methods a(), b() and c() were called in order, and b() was queued, but not the others, it might be the case that c() ends up executing first. Users of this capability would need to be aware of that:

Interesting use context 1. Sending asynchronous messages

No matter what technology is used to send messages, it might be worth having this done using the queued mechanism if we don't care about the result.

Interesting use context 2. Cleanup or similar tasks

The main algorithm could potentially call some kind of cleanup, or garbage collection, or text justification, or spreadsheet calculation operation, or user interface update that would periodically run but not delay the main thread.

Interesting use context 2: Distributed

Currently when using the 'distributed' keyword, all communication is synchronous. This proposed approach would maintain the order of sending of methods, but would still allow the main process to continue. A queued state machine for receiving of calls could also be used (it would result in a separate thread). All methods involved would need to be tagged as queued.

Other alternatives or additions that could be considered

It might sometimes be desirable to slow down the queue processing in some way, to either ensure it has a lower priority, or to test what happens when there are delays. A generated method to be called like 'delayMethodQueue(int ms);' could be available to indicate that queue processing would sleep that number of ms between each attempt to work with the queue. If the argument was 0, the delay would be cancelled. If the argument was negative, then a random delay of up to the absolute value of the amount could be introduced.

This approach would not create more than one extra thread. An alternative design would allow one thread per method, or even one thread per call. We leave that to potential future work.

Another possibility would be to have a stereotype, perhaps simply 'queueAllVoid;' to force all void methods to use the queue.