[perl #22922] Parrot threading!
Graciliano M . P .
# Please include the string: [perl #22922]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22922 >
There is some plan of how threading will work on Parrot?
Since Parrot use registers, like an CPU, how will work the register between the different threads?
Will be a real threading sytem, made by the OS? Or an threading system inside the VM?
How to share data, and objetcs?
And how about objets linkeds with native objetcs (C++), can we share?
How about share a class, and have only the main program with differences?
Beatiful things can be done, specially a fast threading system.
I think that a good way is to make an internal threading system inside the VM, like an OS make in our machines, and we can be able to share native functions/objetcs with that. And also implement threadin in OS that doesn't have this, or where is hard to implement. The biggest problem is with instructions, specially externals, that take some time to process, since this make the other thread wait to go. But some interruption system can be used, to can play the second thread, and go back to the first just after the instruction backs. Or maybe have the 2 styles, one in the OS and one in the VM, and will be possible to work with native threading too (in external libraries).
I think that put threading in the TODO list from the beggining is important, since this is one of the last things to do, but need a lot of changes in the structure and a good work. Plan how to do this from the beggining and make the structure to receive that in the end is important, and Parrot has everything to have a good threading system, since we already saw the different styles in Perl, Java, etc... and know what is good or not.
Regards,
GMP.
Benjamin Goldberg
"Graciliano M . P ." wrote:
>
> # New Ticket Created by Graciliano M. P.
> # Please include the string: [perl #22922]
> # in the subject line of all future correspondence about this issue.
> # <URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22922 >
>
> There is some plan of how threading will work on Parrot?
Each thread will have it's own parrot interpreter.
> Since Parrot use registers, like an CPU, how will work the register
> between the different threads?
Each set of registers belongs to a specific interpreter. Thus, each
thread will have it's own set of registers.
> Will be a real threading sytem, made by the OS? Or an threading system
> inside the VM?
Yes, it will be either an OS threading system or a user space threading
system. There's no reason why it shouldn't work equally well with
pthreads or pth, or any other threading system which provides sufficient
functionality.
Hmm... unless you're thinking of something like Java's green_threads?
Yes, something like that *could* be done... I wouldn't want to be the
one to implement it, though :)
Hmm... once we have event handling done and can create timer events (for
context switches), one could probably build a threading system *on top*
of parrot, without needing to have parrot directly support it.
Hmm... threading implemented by timer/context-switch events might be
quite useful for when we want to run Java on Parrot, since it's all done
with a single interpreter... which is what we need there, since
everything shared across all threads by default.
> How to share data, and objetcs?
<WAG>Probably through a type special "shared" PMC, which contains in
it's data segment a mutex and a pointer to the actual PMC; doing an
operation on this container would lock the mutex, then do the op on the
actual PMC, then unlock the mutex. The containing PMC header would
belong to the interpreter it resides in, the mutex and the contained PMC
would be shared.</WAG>
This is how we'd do it with normal threading (OS supported, or through a
user-level threading library (but still at the C level))... obviously,
if we do something like java's green_threads, then we don't have to do
anything at all to make something shared.
> And how about objets linkeds with native objetcs (C++), can we share?
Similarly to how other data is shared -- a normal PMC header, with
shared stuff in it's data segment.
> How about share a class, and have only the main program with
> differences?
?
> Beatiful things can be done, specially a fast threading system.
>
> I think that a good way is to make an internal threading system inside
> the VM, like an OS make in our machines, and we can be able to share
> native functions/objetcs with that. And also implement threadin in OS
> that doesn't have this, or where is hard to implement. The biggest
> problem is with instructions, specially externals, that take some time
> to process, since this make the other thread wait to go.
This is the same problem that Java's green_threads has. AFAIK, while
one can avoid *some* blockages, there will be times when it's
unavoidable.
E.g., if we perform a blocking read, the VM threading system can detect
what we're trying, and use select() to see if the fd is readable, and if
not, switch to another thread instead of blocking. But if we call some
other native C/C++ function, one which the VM doesn't know how to
schedule around, then the whole VM will block.
> But some interruption system can be used, to can play the second
> thread, and go back to the first just after the instruction backs.
Best yet -- have an OS timer fire off every so often; this enqueues a
timer event. Our normal event handling deques that event, and in the
handler, we would choose to interpret it as a context-switch event --
this saves the continuation which we would "normally" return using,
fetches the continuation of the next thread to wake up, and then
invokcc's that fetched continuation.
We already have plans for supporting each of these things seperately;
turning them into a VM-level threading system might not really be that
hard.
> Or maybe have the 2 styles, one in the OS and one in the VM, and will
> be possible to work with native threading too (in external libraries).
Indeed; further, we can even have multiple OS-threads, and in each of
them, have one or more VM-threads.
> I think that put threading in the TODO list from the beggining is
> important, since this is one of the last things to do, but need a lot
> of changes in the structure and a good work. Plan how to do this from
> the beggining and make the structure to receive that in the end is
> important, and Parrot has everything to have a good threading system,
> since we already saw the different styles in Perl, Java, etc... and
> know what is good or not.
What I want to know, is what happens if we try and pass a continuation
(or a subroutine, for that matter) from one thread to another, and then
invoke it in the wrong thread? :)
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
Dan Sugalski
># New Ticket Created by Graciliano M. P.
># Please include the string: [perl #22922]
># in the subject line of all future correspondence about this issue.
># <URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22922 >
>
>
>There is some plan of how threading will work on Parrot?
Yes. (Though there's some disagreement to the solidity and sanity of
the plan :)
>Since Parrot use registers, like an CPU, how will work the register
>between the different threads?
Each thread is essentially a separate CPU in a loosely-coupled SMP
system, so each thread has separate registers.
>Will be a real threading sytem, made by the OS? Or an threading
>system inside the VM?
A real system.
>How to share data, and objetcs?
How? Well... That's somewhat up in the air.
>And how about objets linkeds with native objetcs (C++), can we share?
Best make sure the wrapper class implements the required level of
synchronization. That's going to be left to the folks writing the
wrappers, as it's not something that can be done automatically.
>How about share a class, and have only the main program with differences?
Not sure what you're getting at here, sorry.
>Beatiful things can be done, specially a fast threading system.
Yep. I'm rather fond of erlang for that sort of thing. I'm not sure
that we're going to go that way, since our needs are somewhat
different.
>I think that a good way is to make an internal threading system
>inside the VM, like an OS make in our machines, and we can be able
>to share native functions/objetcs with that.
Properly implementing our own threading system is a swamp worse than
portable async I/O. It just isn't worth it, and since most of the
platforms we want to run on already have a working POSIX-equivalent
thread system in place (OK, the Gameboy Advance doesn't, but...) it'd
be wasted work. It'd be worth it for those places that don't have
threads already, but that's mostly in the embedded space and it'd be
easier to weld that in underneath Parrot as it is.
>I think that put threading in the TODO list from the beggining is important,
It's been there from the beginning. :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk