I might have some more to say about any threading model later, but for now I wanted to make everyone aware of a scripting language that is "truly" multi-threaded - you may want to check it out. Some of it's syntax is Perlish, whereas some is not - the point is that it is supposed to scale on SMP machines.
It's called Qore - http://www.qore.org. I maintain the FreeBSD port for it and have played with it quite a bit. It's a nice interface - though traditional. And it does seem to scale pretty well. If the debate is shared memory threads vs message passing (ala Erlang), then I would suggest that they are not mutually exclusive (pun intended) and could actually provide some complementary benefits if deployed on a large scale distributed memory machine composed of SMP nodes. In otherwords, a mixed mode style of distributed programming where the SMP threads run on each node and the MP is used to connect these disjoint processes over the network. I know that the SMP threads is best implemented with a low level runtime (maybe even using a Qore backend?), but I have no idea how one might facilitate Erlang style remote processes - still, I believe offering both styles would be totally awesome :^). Cheers, Brett On Wed, May 12, 2010 at 09:50:19AM -0300, Daniel Ruoso wrote: > Em Ter, 2010-05-11 ??s 21:45 -0300, Daniel Ruoso escreveu: > > The threading model topic still needs lots of thinking, so I decided to > > try out some ideas. > > After BrowserUK feedback and some more reading (including > http://www.c2.com/cgi/wiki?MessagePassingConcurrency ) and links from > there on, I decided to rewrite that ideas in a bit different model, but > still with the same spirit. > > 0 - The idea is inspired by Erlang and the IO Language. Additionally > to OS threads there are the "Coroutine Groups". > > 1 - No memory is shared between "Coroutine Groups", so no locking is > necessary. > > 2 - A value and a coroutine always belong to a "Coroutine Group", > which should be assigned to a single OS thread, thus naturally > implementing synchronized access to data. > > 3 - The interpreter implements a scheduler, which will pick one of the > "waiting" coroutines that belong to the groups assined to the > current thread. The scheduler may also suspend a coroutine in > order to implement time-sharing. The scheduler should support > "blocking" states in the coroutines. > > 4 - When comparing to Perl 5, each coroutine is an ithread, but memory > is shared between all the coroutines in the same group, given that > they will always run in the same OS thread. > > 5 - When a coroutine group is created, it is assigned to one OS > thread, the interpreter might decide to create new OS threads as > necessary, it might optionally implement one OS thread per > "coroutine group". > > 6 - In order to implement inter-coroutine-group communication, there > are: > > 6.1 - A "MessageQueue" works just like an Unix Pipe, it looks like > a slurpy array. It has a configurable buffer size and > coroutines might block when trying to read and/or write to > it. > > 6.2 - A "RemoteInvocation" is an object that has a identifier, a > capture (which might, optionally, point to a "MessageQueue" > as input) and another "MessageQueue" to be used as output. > New coroutines are created in the target group to execute > that invocation. > > 6.3 - An "InvocationQueue" is a special type of "MessageQueue" > that accepts only "RemoteInvocation" objects. > > 6.4 - A "RemoteValue" is an object that proxies requests to > another coroutine group through a "RemoteInvocation". > > 7 - The coroutine group boundary is drawn by language constructs such > as async, the feed operator, junctions, hyper operators. > > 8 - A value might have its ownership transferred to another group if > it can be detected that this value is in use only for that > invocation or return value, in order to reduce the amount of > "RemoteInvocation"s. > > 9 - A value might do a special "ThreadSafe" role if it is thread-safe > (such as implementing bindings to thread-safe native libraries) In > which case it is sent as-is to a different group. > > 10 - A value might do a special "ThreadCloneable" role if it should be > cloned instead of being proxied through a "RemoteValue" when sent > in a "RemoteInvocation". > > 11 - The "MessageQueue" notifies the scheduler whenever new data is > available in that queue so the target coroutine might be raised. > > 12 - Exception handling gets a bit hairy, since exceptions might only > be raised at the calling scope when the value is consumed. > > 13 - List assignment and Sink context might result in synchronized > behavior. > > comments are appreciated... > > daniel > -- B. Estrade <estr...@gmail.com>
