On Tue, Oct 12, 2010 at 3:46 PM, Tim Bunce <tim.bu...@pobox.com> wrote:
> On Tue, Oct 12, 2010 at 03:42:00PM +0200, Leon Timmermans wrote:
>> On Mon, Oct 11, 2010 at 12:32 AM, Ben Goldberg <ben-goldb...@hotmail.com>
>> wrote:
>> > If thread-unsafe subroutines are called, then something like ithreads
>> > might be used.
>>
>> For the love of $DEITY, let's please not repeat ithreads!
>
> It's worth remembering that ithreads are far superior to the older
> 5005threads model, where multiple threads ran with an interpreter.
> [Shudder]
>
> It's also worth remembering that real O/S level threads are needed to
> work asynchronously with third-party libraries that would block.
> Database client libraries that don't offer async support are an
> obvious example.
Hi,
I'm showing up only because I happened to check my Perl 6 inbox. For
various work related reasons, I'd peeked my head into a couple other
language VMs threading implementations. Seems relevant to mention more
possibilities:
ruby-1.8:
- green threads
- single actual process
- scheduling handled by switching to "something else" after N
opcodes are dispatched
- system() and other blocking system calls are implemented as
non-blocking alternatives
- C extensions must also use non-blocking code and be written
to call back to the scheduling core
- able to share data easily without onerous user-level
synchronization because there's really no such thing as being
concurrent
ruby-1.9 + python:
- real threads
- global interpreter lock over the core so they're not CPU concurrent
- don't have the story for C extensions
- able to share data easily without onerous user-level
synchronization because there's really no such thing as being
concurrent
jruby:
- Java
- real threads
- fully concurrent
- mostly can't use C extensions
- able to share data easily without onerous user-level
synchronization because ... ? Java magic?
Those implementations all do very well for tasks where actual CPU
concurrency isn't needed. A common sweet spot are web services and
other things that divide time over IO waiting. They also do well by
not having to instantiate separable VMs per thread. They also don't
require the user (as in Perl 5) to carefully mark their data as shared
because by default everything is shared (but then they don't have
actual concurrency either).
They do poorly when expected to take advantage of multiple cores. When
using this kind of concurrent software for web services, I've
compensated by just running enough processes to keep my CPUs busy. I
got the advantage of having something that behaved like threads but
was extremely easy to work with. This is very unlike my experience
with Perl 5 threads which I still fear to work with (mostly because I
worry of dangling pointers from difficult to spot miscellaneous magic
attachments).
Our own threading story could use tricks from the above and include
more than just what you've mentioned.
Josh
