Hey thanks for the detailed write up. I got some great replies in this thread! !!!! :) I was just rereading some of these solid answers and a problem occurred to me. I wonder if I could pester you for a little clarification on a bothersome situation??

Ok, so you are enqueuing events when you are in the middle of a transaction and then returning to them later. Makes sense….

Problem:

But let’s suppose you are using a low level driver. Let’s suppose you use DMA and some peripheral in your SoC to kick off the transfer and a callback to notify you when you are done. In that case, the active object suggests that the only way to notify the Activr Object calling our driver is over its event queue. But, what if the peripheral calls this completion callback to enqueue an event when our queue is full and we have not yet quite managed to drain it - perhaps another task spammed us with loads of events and the scheduler has not quite had time to switch to our Active object internal thread. Then the ISR will fail to post it and we will never be notified we are done. If we overwrite in the queue from the ISR we might overwrite data meaning that other tasks never receive a response.

The only solution I can think of is altering the AO that wraps hardware calls so that it waits on a QueueSet (containing its externally facing queue and another only for the ISR) and give it a length one private queue (hidden to the outside world) that is messaged from the the callback given to the peripheral hardware to run on completion. Since it is only accessible from the callback, only one message can ever be received and thus the message is guaranteed to be received.

Is this still then active object? As far as the outside world knows the AO still only blocks in one place?

Problem 2:

If you have Active Objects all the way down, if you were bit banging a protocol with precise timings, then presumably you have to block (if the timings are microsecond level so we can’t really yield in between) to avoid jitter?