[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

basic threading question: can ruby use real threads?

Kyle Schmitt

5/8/2007 8:53:00 PM

I've read somewhere, and would love for it to be wrong, that ruby
doesn't use real threads, that it handles it's threads internally. Is
that true? If it is true, will that still be true when ruby 1.9, or
2.0 comes out?

For many systems this isn't a big deal one way or the other, since
they only have one physical processor. Luckily(?) pretty much all my
systems have two procs. (Two real processors, not HT, but that's a
debate for another day.) I'd like to write some threaded ruby code,
and have it spread across my cpus, share data structures etc.

I'm used to pthreads in UNIX systems :) so I'd _really_ like it if I
could do the same type of things I've done before, just in a rubyish
sort of way. Setting up a shared memory area and all that jazz that
you had to do for forking really doesn't sound like a fun, especially
when the point of the code I wanna write _is_ for fun.

Thanks,
Kyle
35 Answers

James Gray

5/8/2007 8:59:00 PM

0

On May 8, 2007, at 3:52 PM, Kyle Schmitt wrote:

> I've read somewhere, and would love for it to be wrong, that ruby
> doesn't use real threads, that it handles it's threads internally. Is
> that true? If it is true, will that still be true when ruby 1.9, or
> 2.0 comes out?

This was recently discussed in detail by the creators:

http://blog.grayproductions.net/articles/2007/04/27/th...
episode-iii

James Edward Gray II

Kyle Schmitt

5/8/2007 9:03:00 PM

0

Sweet, thanks for the link!

Kyle Schmitt

5/8/2007 9:34:00 PM

0

OK, so I'm reading that article, and I'm getting three things form it:
YARV uses native threads.
YARV doesn't run them simultaneously.
YARV will eventually run them simultaneously.

Good enough for me, I'll just hope that writing threaded code doesn't
change to much with ruby2.0/YARV.

--Kyle

Henry Maddocks

5/8/2007 9:40:00 PM

0

Quoting Kyle Schmitt <kyleaschmitt@gmail.com>:

> I've read somewhere, and would love for it to be wrong, that ruby
> doesn't use real threads, that it handles it's threads internally. Is
> that true?

You have heard correctly and yes it is a pain.

Marcin Raczkowski

5/9/2007 4:00:00 PM

0

On Tuesday 08 May 2007 21:34, Kyle Schmitt wrote:
> OK, so I'm reading that article, and I'm getting three things form it:
> YARV uses native threads.
> YARV doesn't run them simultaneously.
> YARV will eventually run them simultaneously.
>
> Good enough for me, I'll just hope that writing threaded code doesn't
> change to much with ruby2.0/YARV.
>
> --Kyle

well you can use fastthreads gem (part of mongrel)
also you can fork your script ^^ threads usually execute on same processor
AFIK, that's why if you want to use 2 processors you have to fork your
scripts, and if you need comunication between them consider using drb.

very good gem is slave - it makes creating new processes super easy - it
provides easy way to comunicate, so you can create 4-6 new processes each
will get data to compute from mother process and the'll use both processors

sorry for lots of randomness and strange grammar - to much coffeine
to sumarize - read rdoc for gems:
- fasthread(s)
- slave(s)
(i never remember if they are plurar or singular)

--
Marcin Raczkowski
---
Friends teach what you should know
Enemies Teach what you have to know

MenTaLguY

5/9/2007 6:28:00 PM

0

On Thu, 10 May 2007 01:00:04 +0900, Marcin Raczkowski <swistak@mailx.expro.pl> wrote:
> well you can use fastthreads gem (part of mongrel)

fastthread just makes the locking primitives from thread.rb a little faster; it doesn't otherwise affect the operation of Ruby threads. Additionally, it is applicable only to Ruby 1.8, not YARV/1.9.

-mental

Marcin Raczkowski

5/9/2007 6:58:00 PM

0

On Wednesday 09 May 2007 18:27, MenTaLguY wrote:
> On Thu, 10 May 2007 01:00:04 +0900, Marcin Raczkowski
<swistak@mailx.expro.pl> wrote:
> > well you can use fastthreads gem (part of mongrel)
>
> fastthread just makes the locking primitives from thread.rb a little
> faster; it doesn't otherwise affect the operation of Ruby threads.
> Additionally, it is applicable only to Ruby 1.8, not YARV/1.9.
>
> -mental

I didn't say it makes use of POSIX threads - i just recomended it becouse they
are well ... faster.

only thing right now that'll let you use botht procesors is fork

--
Marcin Raczkowski
---
Friends teach what you should know
Enemies Teach what you have to know

Kyle Schmitt

5/9/2007 7:04:00 PM

0

If you fork, is there even a way to create objects that are shared
between the two forks? Or do you have to rely on rpc/ipc stuff
instead?


If someone were to... write a c extension who's objects were threaded,
via pthreads, would it be a nightmare?

Even just typing that line almost scares me....but I can think of some
clean(ish?) ways of doing it. I'm just worried I'd loose the rubyness
of the thing if I did it that way.

Thanks,
Kyle

Gary Wright

5/9/2007 7:21:00 PM

0


On May 9, 2007, at 2:57 PM, Marcin Raczkowski wrote:
> I didn't say it makes use of POSIX threads - i just recomended it
> becouse they
> are well ... faster.
>
> only thing right now that'll let you use botht procesors is fork

Just my opinion but my default choice would be fork when I need
concurrency rather than threads. The main reason is that it forces you
to be explicit in how you structure the communication between processes.
One process can't inadvertently change the state of another.
On a multi-processor box you'll get IO multiplexing and real CPU
concurrency automatically with fork.

Some problems can't be partitioned easily into separate addresses
spaces,
in which case threads are a better choice. Even then I might consider
using shared memory among cooperating processes first.

I realize that the Unix fork/exec model of processes doesn't quite apply
in the Windows environment. Anecdotal evidence makes me think that
Windows programmers tend to reach for threads as a multi-tasking
solution
more often than Unix programmers.

One more observation. The desire for real concurrency using multiple
processors is great for problems that can be cleanly partitioned, but if
you have a problem that requires concurrent access to shared data then
you'll have to keep in mind the memory/cache contention that will be
created when processing is distributed across multiple processors (via
processes or threads).

Gary Wright

MenTaLguY

5/9/2007 7:35:00 PM

0

On Thu, 10 May 2007 04:03:57 +0900, "Kyle Schmitt" <kyleaschmitt@gmail.com> wrote:
> If you fork, is there even a way to create objects that are shared
> between the two forks? Or do you have to rely on rpc/ipc stuff
> instead?

Totally RPC. You could use DRb to do this in a Rubyesque fashion.

It's worth noting that no matter _what_ threading approach you use, it's
absolutely best to minimize the number of objects shared between threads.

> If someone were to... write a c extension who's objects were threaded,
> via pthreads, would it be a nightmare?

Yes, somewhere between nightmare and flesh-rending terror. At least if you're
planning on manipulating Ruby objects from each thread.

You might want to consider using JRuby instead. It's compatible enough with MRI
that it runs Rails, and it uses "real" threads for multi-CPU goodness.

-mental