On 2 December 2016 at 11:18, Bill Fischofer
wrote:
> This is a good discussion. The key is to recognize that the ordering
> provided by ordered queues is of contexts, not events. When the
> scheduler dispatches an event from an ordered queue, it creates an
> ordered
This is a good discussion. The key is to recognize that the ordering
provided by ordered queues is of contexts, not events. When the
scheduler dispatches an event from an ordered queue, it creates an
ordered context that the receiving thread now runs in. That context is
ordered with respect to all
On 1 Dec 2016, at 6:58, Yi He > wrote:
Hi, thanks Matias
The example is very helpful, one question follow it:
Previously I understand atomic queue like multiple producer/single consumer
behaviour, so producers (enqueue threads) can still run in
Hi, thanks Matias
The example is very helpful, one question follow it:
Previously I understand atomic queue like multiple producer/single consumer
behaviour, so producers (enqueue threads) can still run in parallel?
But in the example the two producer threads behaves like sequentially while
On 28 Nov 2016, at 12:19, Yi He >
wrote:
Thanks Matias
Very clearly documented:
“
* Event ordering is based on the
* received event(s), but also other (newly allocated or stored) events are
* ordered when enqueued within the same ordered context.
“
Thanks Matias
Very clearly documented:
“
* Event ordering is based on the
* received event(s), but also other (newly allocated or stored) events are
* ordered when enqueued within the same ordered context.
“
One question is that for scheduled events, their order are very clear
determined by
On 28 Nov 2016, at 7:58, Yi He >
wrote:
Hi, Bill, Matias
For this bug related to the validation scheduler test program, with errors
like:
scheduler.c:878 - bctx->sequence == seq
I saw a potential problem in the validation scheduler program code