Arthur Bergman wrote:
> > Arthur Bergman wrote:
> >
> > > In an effort to rest my braine from a coredumping perl5 I started to think a bit
>on threading under parrot?
> > >
> > > While it has been decided that perl should be using ithread like threading, I
>guess that is irelevant at the parrot level. Are you
> > > going to have one "virtual cpu" per thread with it's own set of registers or are
>you going to context switch the virtual cpu?
> > >
> > > If it was one virtual cpu per thread then one would just create a new virtual
>cpu and feed it the bytecode stream?
> > >
> > > Is there anything I could help with regarding this?
> > >
> > > Arthur
> >
> > The context is almost identical to that of Perl5's MULTIPLICITY which passes the
>perl-interpreter to each op-code. Thus there is
> > inherent support for multiple ithread-streams. In the main-loop (between each
>invoked op-code) there is an event-checker (or was in
> > older versions at any rate). It doesn't do anything yet, but it would make sence
>to assume that this is where "context-switches"
> > would occur, which would simply involve swapping out the current pointer to the
>perl-context; A trivial matter.
>
> Uhm, are you talking perl 5 here? The event checker checks for signals, we got safe
>signals now.
There wasn't any code for CHECK_EVENTS w/in Parrot when I first read the source-code.
I merely assumed that it's role was not-yet determined, but considered the possible
uses. CHECK_EVENTS seems to be gone at the moment, so it's a moot point.
> MULTIPLICITY is just allowing multiple interpreters, ithreads is letting them run at
>the same time and properly clone them. If you want to use it switch interpreters at
>runtime for fake threads, patches are welcome, send it and I will apply it.
>
>
> > The easiest threading model I can think of would be to have a global var called
>"next_interpreter" which is always loaded in the
> > do-loop. An asynchronous timer (or event) could cause the value of
>"next_interpreter" to be swapped. This way no "schedule"
> > function need be checked on each operation. The cost is that of an extra
>indirection once per op-code.
> >
> > True MT code simply has each thread use it's own local interpreter instance.
>MT-code is problematic with non MT-safe extensions
> > (since you can't enforce that).
>
> I am sorry to say, but perl 5 is true MT.
Yes, but that feature never got past being experimental. I know of a couple DBDs that
would not let you compile XS code with MT enabled since they weren't MT-safe. The
interpreter can be built MT-safe (java is a good example), but extensions are always
going to be problematic. (Especially when many extensions are simply wrappers around
existing non-MT-aware APIs). I think a good solution to them would be to tread it
like X does (which says you can only run X-code w/in the main-thread). An extension
could say whether it was MT-safe or not, and be forced to be serialized w/in the
main-physical-thread, which becomes the monitoring thread. An alternative would be to
simply
have XS code compile in a flag which says to throw an exception if the code is run
outside of the main-thread; Documentation would emphatically state that it's up to
the user to design the system such that only the main-thread calls it.
On the side, I never understood the full role of iThreads w/in perl 5.6. As far as I
understood, it was merely used as a way of faking "fork" on NT by running multiple
true-threads that don't share any globals. I'd be curious to learn if there were
other known uses for it.
>
>
> > In iThread, you don't have a problem with atomic operations, but you can't take
>advantage of multiple CPUs nor can you garuntee
> > prevention of IO-blocking (though you can get sneaky with UNIX-select).
> >
>
> Where did you get this breaking info? ithread works with multiple CPUs and IO
>blocking is not a problem.
>
> Arthur
I'm under the impression that the terminology for iThreads assumes an independance of
the physical threading model. As other posters have noted, there are portability
issues if we require hardware threading. Given the prospect of "falling back to
fake-threads", then multi-CPU and IO blocking is problematic; though the latter can be
avoided
/ minimized if async-IO is somehow enforced. From my scarce exposure to the Linux
Java movement, "green-threads" were considered more stable for a long time, even
though the porters were just trying to get things to work on one platform.
I would definately like hardware threading to be available. If nothing else, it lets
students taking Operating Systems to experiment with threading w/o all the headaches
of c. (Granted there's Java, but we like perl) However, I'm not convinced that
threading won't ultimately be restrictive if used for generation operation (such as
for the
IO-subsystem). I'm inclined to believe that threading is only necessary when the user
physically wants it (e.g. requests it), and that in many cases fake-threads fulfill
the basic desires of everyone involved (robustness comming from atomic activity,
coupled with multiple non-blocking streams of execution), and in the rare case that
true
hardware-MT is desired (possibly for multi-CPU utilization), there can be a security
layer wrapped around it such as if non-MT-safe XS code is executed outside of the
main-thread an exception is thrown.
Ideally the API is thread-implementation egnostic. I've seen posts that suggest
coding the "call-back" structure in the compiler and simply providing special op-codes
which allow the creation of threads. This could work, but then compatibility wouldn't
be maintained if the underlying design shifted (which would probably be the case
anyway). If the op-codes themselves were the only things that knew anything about the
physical implementation of threading, then the compiler(s) wouldn't need to change.
The op-codes could be configured (at parrot-build-time) to use any of the several
different physical models. I'm convinced that the best model is a combination of sync,
async and threading that is different for different tasks. The more the underlying
system can do to choose the best path, the more valuable this new development platform
will be.
As an example. If code doesn't invoke any new threads, then all operations should be
synchronous. If there is only one CPU, then there's little advantage of running
physical threads over fake threads (which is known at parrot-build-time); though there
are definately some cases. Fake threaded code can easily context switch by simply
swapping interpreter pointers. hardware-threaded code that implements monitoring (for
safe XS-code) can immediately instantiate a monitoring thread on the first requested
thread-fork. The op-codes could dispatch all non MT-safe XS code to this monitoring
thread (blocking until completion). I'd like to hear more discussion as to peoples
concerns or interests on these concepts.
In all, I'm just arguing that xThreading is a complex issue, and I'm trying to insight
some discussions as to which models are best - given parrot's current framework.