On Wed, Aug 3, 2011 at 9:57 AM, BGB <cr88...@gmail.com> wrote: > maybe some good alternative is needed to the traditional "threading and > locks" model so prevalent in modern mainstream languages.
[...] now whether any of this could make threading easier to use... I really have > little idea... maybe there is some fundamentally better way to approach multi-threaded > code?... I'm partial to the 'vats and turns' model as seen in E language, assuming you want something readily leveraged in OO languages. In the 'vat' model, every object belongs to just one vat, and there is no shared memory (no shared variables, anyway) between vats. However, object references may be shared between vats. Messages from one vat always target a specific object in another vat, and are ordered (which helps with reasoning about progress, fairness, and sane causal relationships). Each vat is single-threaded. I've developed a variation of vats using temporal semantics for real-time programming. The short version: each vat has a logical time, which moves towards the current time - as measured by a logical clock. Vats also regulate the clock, preventing the clock's time from advancing too far ahead of their vat time. The idea is to allow threads to drift some - for performance and efficient batching - while also preventing starvation or priority inversion between vats in a process. I can also use the limit on progress to achieve determinism in my commutative programming model, RDP. Events between vats tend to queue up and get processed in an implicit batch. This batching easily achieves two orders of magnitude performance gain relative *even to lightweight threads*. E.g. I see a 40x improvement when switching from 1 token to 1000 tokens in a simple TokenRing benchmark. Scheduling within a vat is even more efficient - I get another 40x improvement there, at which point I hit CPU limits (~100 cycles for a simple operation, including the full life-cycle: allocation, enqueue, dequeue, run, GC). Of course, a token ring is a degenerate case. But 'bursty traffic' is not uncommon, and I would most operations to amortize that ~100 cycle overhead further. A 'straggling' vat can hold up all others on the same clock. This is a mixed blessing - i.e. performance issues are very easy to detect, isolate, and correct, but developers must replace monolithic algorithms (at least those that might take a long time, such as ray-tracing) with incremental ones. Anyhow, I would most certainly recommend you look into E language vats for your own purposes. They are far easier to reason about and handle than 'async' function calls and 'synchronized' methods. The advantages: * locally deterministic; easy to validate a vat up to input. * ordering of messages between vats is easy to reason about; determinism between vats is achievable with a few simple practices. * fairness and progress are easy to reason about; real-time is feasible with a few simple practices. * you can easily isolate performance issues specific vats. * since vats are only accessed through object references (there are no 'vat references'), developers have a nice decoupling property that allows them to transparently break an application into more or fewer vats as needed to leverage available parallelism. * since vats are accessed through object references, we can pass references between vats and thus 'introduce' one vat to another. That is, we can eliminate any 'centralized dispatch' at runtime.
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
