Re: ring buffer

[Sébastien Doeraene]

Hi,

(replying to mozart-hackers)

The thread pool is single-threaded. This technology addresses contention issues between different threads using queues. So it does not apply to the thread pool.

For the DSS, again, one Oz VM is single-threaded. It shares no memory with other VMs running in parallel. So I don't see what this would bring.

Cheers,

Sébastien

On Wed, Dec 4, 2013 at 10:00 PM, stewart mackenzie <seto...@gmail.com> wrote:

Hi there,

I'd like you to read over this ring buffer created by LMAX.

http://disruptor.googlecode.com/files/Disruptor-1.0.pdf

It might be a good idea to refactor the thread pool in the virtual
machine to make use of this algorithm.

It might even be possible to have an oz implementation used for the DSS.

Kind regards
Stewart

[Stewart Mackenzie]

Pardon my ignorance, but a thread pool cannot be single threaded, maybe the implementation of the manager is but it deals with multiple threads. Hence a pool of threads.

Oz threads are managed by c++ queues. At some point there should be locking going on in c++ land to manage oz dataflow calculations. Although oz dataflow vars don't lock then unlock as c++ semaphores do, its more cooperative than competitive.

This disrupter technology replaces actors, at a fundamental level (read that Kernel Oz paper IIRC) oz is actor based. Hence this could be applied?

Forget the dss, I was looking at the buy sell forex messages to this disrupter and applying it to messages coming into the dss. Still need to think some more.

Essentially this is a deterministic way of doing concurrency, oz too is deterministic hence couldn't this hack on a low level reveal a deterministic super fast oz? But doesnt makes use of queues prone to being either empty or full.

I'm still trying to wrap my head around this tech and how to apply it to different areas. So do be patient with me.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.