Em Ter, 2010-05-11 às 21:45 -0300, Daniel Ruoso escreveu:
> he threading model topic still needs lots of thinking, so I decided to
> try out some ideas.
After I sent the second version, I just realized I could make it simpler
by just assuming "one OS thread per Coroutine Group"... so here goes the
new version.
0 - No memory is shared between threads, so no locking is necessary.
1 - A value and a coroutine always belong to a thread, thus naturally
implementing synchronized access to data.
2 - Coroutines are, conceptually, the equivalent to green threads,
running in the same OS thread. Coroutines waiting for a return
value are "blocked".
3 - The interpreter implements a scheduler, which will pick one of the
"waiting" coroutines, it may also suspend a coroutine in order to
implement time-sharing.
4 - In order to implement inter-thread communication, there are:
4.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.
4.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 thread to execute
that invocation.
4.3 - An "InvocationQueue" is a special type of "MessageQueue"
that accepts only "RemoteInvocation" objects.
4.4 - A "RemoteValue" is an object that proxies requests to
another coroutine group through a "RemoteInvocation".
5 - The thread group boundary is drawn by language constructs such
as async, the feed operator, junctions, hyper operators.
6 - A value might have its ownership transferred to another thread 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.
7 - 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 thread.
8 - 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".
9 - Exception handling gets a bit hairy, since exceptions might only
be raised at the calling scope when the value is consumed.
10 - List assignment and Sink context might result in synchronized
behavior.
daniel
