> On July 31, 2017, 9:05 p.m., Dario Rexin wrote: > > 3rdparty/libprocess/src/event_queue.hpp > > Lines 328 (patched) > > <https://reviews.apache.org/r/61058/diff/3/?file=1785564#file1785564line331> > > > > I don't think this queue matches the requirements for an actor system. > > This queue uses sub-queues as a performance optimization and the ordering > > between the different queues is not guaranteed. The assumption here is, > > that causal ordering only needs to be maintained per thread. In an actor > > system however, there is no guarantee on which thread an actor will run. > > Think of following scenario: > > > > Actor A receives a burst of messages and takes some time to process > > them. > > > > Actor B receives a message gets dispatched to Thread 1 and sends a > > message to Actor A. The queue of Actor B is now empty, so it donates the > > thread back to the pool. > > > > Actor A is still busy processing the messages it received earlier and > > did not process the message that Actor B sent. > > > > Actor B receives another message and gets dispatched to Thread 2. It > > now sends another message to Actor A. > > > > Now Actor A received 2 messages from Actor B from 2 different threads. > > The moodycamel queue does not guarantee the order of those messages. This > > violates the arrival ordering defined in the actor model and makes it > > impossible to reason about message ordering between two actors. > > Benjamin Hindman wrote: > For posterity, to account for this "deficiency" in the concurrent queue > we've forced the _single_ consumer semantics on the queue and let the > consumer reorder any events when the read them out. See the lock-free > implementation of `EventQueue::try_dequeue` for more details. > > Dario Rexin wrote: > Clarified with benh and benm. There's additional code that restores > ordering.
-.- I forgot to click publish - Dario ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/61058/#review181840 ----------------------------------------------------------- On July 29, 2017, 8:52 p.m., Benjamin Hindman wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/61058/ > ----------------------------------------------------------- > > (Updated July 29, 2017, 8:52 p.m.) > > > Review request for mesos and Benjamin Mahler. > > > Bugs: MESOS-7798 > https://issues.apache.org/jira/browse/MESOS-7798 > > > Repository: mesos > > > Description > ------- > > Added a lock-free event queue. > > > Diffs > ----- > > 3rdparty/libprocess/configure.ac cb2cf4f32be5cbdf9df1e32f9aaf2bbba0a5ae03 > 3rdparty/libprocess/src/event_queue.hpp PRE-CREATION > 3rdparty/libprocess/src/process.cpp > b268cdad776a3ca2a87cbe60eb098bde2a70667c > > > Diff: https://reviews.apache.org/r/61058/diff/3/ > > > Testing > ------- > > make check > > > Thanks, > > Benjamin Hindman > >
