A question on Ruby Threads 
Author Message
 A question on Ruby Threads

hello

this is more of a general question on Ruby Threads.
I have never used threads in any language until now, so
I am a complete newbie to this topic.
(have read something about threads in a bad java book,
but this didn't help me with the following questions)

I read somewhere that Ruby threads are no native threads.

what exactly is a native thread?? (something using pthreads on linux??)

what is the advantage / disadvantage of the ruby approach to threads??

are native threads faster??

Does anybody know, if the python and Perl Thread implementations are similar
to the ruby Thread implementation??

I tried to find some answers on the web but couldn't find anything
useful.

thanks in advance for all answer!

regards
markus



Sun, 04 Jul 2004 16:42:07 GMT  
 A question on Ruby Threads

Quote:
> hello

> this is more of a general question on Ruby Threads.
> I have never used threads in any language until now, so
> I am a complete newbie to this topic.
> (have read something about threads in a bad java book,
> but this didn't help me with the following questions)

I'm a Ruby newbie but I'll take a shot.

Quote:
> I read somewhere that Ruby threads are no native threads.

That's right.

Quote:
> what exactly is a native thread?? (something using pthreads on linux??)

Yes, pthreads on Unix and the WIN32 threads on Windows.

Quote:
> what is the advantage / disadvantage of the ruby approach to threads??

> are native threads faster??

The Ruby method is portable. I don't think it's as fast and it can't use
more than one processor at a time.

Quote:
> Does anybody know, if the Python and Perl Thread implementations are similar
> to the ruby Thread implementation??

I'm not sure. Matz has hinted that Ruby 2.x will use native threads.

Quote:
> I tried to find some answers on the web but couldn't find anything
> useful.

< http://www.*-*-*.com/ ~bos/threads-faq/>
Sherlock rocks.
--
{*filter*}s are obsolete children.
-Dr. Seuss, humorist, illustrator, and author (1904-1991)


Sun, 04 Jul 2004 22:38:30 GMT  
 A question on Ruby Threads

Quote:


>> hello

>> this is more of a general question on Ruby Threads. I have never used
>> threads in any language until now, so I am a complete newbie to this
>> topic. (have read something about threads in a bad java book, but this
>> didn't help me with the following questions)

> I'm a Ruby newbie but I'll take a shot.
>> I read somewhere that Ruby threads are no native threads.

> That's right.
>> what exactly is a native thread?? (something using pthreads on

linux??)

A native thread is a execution path through a process space with shared
memory intra-process, but which takes it own singular execution path.
Basically, it's a piece of the process that can do it's own work, but
doesn't get it's own memory. NATIVE threads are different than PThreads
in that native threads are kernel-schedulable entities, whereas PThreads
are not known to the kernel (i.e. a process using PThreads will appear to
be a single-threaded process to the kernel).

Quote:

> Yes, pthreads on Unix and the WIN32 threads on Windows.

PThreads are not native threads. PThreads is a package created at MIT to
faciliate portable threading model. Tthey are user-space threads
(switched by the process itself, susceptible to full process-block on
single thread blocking).

Quote:
>> what is the advantage / disadvantage of the ruby approach to threads??

>> are native threads faster??

> The Ruby method is portable. I don't think it's as fast and it can't use
> more than one processor at a time.

The disadvantages are that one thread can cause the entire process to
block, and the kernel knows nothing of the threads inside a Ruby process.
Thus it cannot optimize access for said threads. However, that is also
it's strength, as Ruby threads need not make system calls to switch
between themselves. This actually results in faster running times in some
cases. Also, what Chris said is true, PThreads cannot take advantage of
multiple processor machines as native threads can.

Quote:

>> Does anybody know, if the Python and Perl Thread implementations are
>> similar to the ruby Thread implementation??

Python uses the same portable-thread-type scheme as Ruby. I know nothing
of Perl's threading mechanisms, or even if it has them.

Quote:
> I'm not sure. Matz has hinted that Ruby 2.x will use native threads.

If Ruby is successfully ported to Parrot, it will have native thread
access. Parrot is supposed to implement native threading on all supported
platforms.

Quote:
>> I tried to find some answers on the web but couldn't find anything
>> useful.
> <http://www.serpentine.com/~bos/threads-faq/> Sherlock rocks.

A good introduction to threading in general would probably be the
comp.programming.threads FAQ, found here:

http://www.serpentine.com/~bos/threads-faq/

Good luck! But watch out for those race conditions! ;-) (little thread
humor.... I know, I'm a geek)
--
I sense much NT in you.
NT leads to Bluescreen.
Bluescreen leads to downtime.
Downtime leads to suffering.
NT is the path to the darkside.
Powerful Unix is.



Sun, 04 Jul 2004 23:21:28 GMT  
 A question on Ruby Threads

Quote:

> PThreads are not native threads. PThreads is a package created at MIT to
> faciliate portable threading model. Tthey are user-space threads
> (switched by the process itself, susceptible to full process-block on
> single thread blocking).
>From what I understand, pthreads are POSIX threads, and can be

implemented in user space or in kernel space.  MIT Pthreads is an
implementation of POSIX threads in user space.  LinuxThreads is also an
implementation of POSIX threads, but its threads are kernel-level
threads.

Paul



Sun, 04 Jul 2004 23:26:59 GMT  
 A question on Ruby Threads

Quote:

> this is more of a general question on Ruby Threads. I have never used
> threads in any language until now, so I am a complete newbie to this
> topic. (have read something about threads in a bad java book, but this
> didn't help me with the following questions)

You can't find the truth in a bad java book any more than by watching
infomercials.

Quote:
> I read somewhere that Ruby threads are no native threads.

That's still true. Matz mentioned native threads for 2.0.

Quote:
> what exactly is a native thread?? (something using pthreads on linux??)

AFAIK, pthreads are "abstract" threads, and are implemented as native
threads on Linux, but then, I could be wrong (i haven't used them myself).
If not you can create your own native threads by using fork() for
splitting processes and mmap() for sharing memory.

Quote:
> what is the advantage / disadvantage of the ruby approach to threads??
> are native threads faster??

ruby threads are "user threads" (or "user-mode threads"), and they're also
"cooperative". "User" means does not involve the kernel more than strictly
necessary (maybe just for a timer). "Cooperative" means that the scheduler
is not invoked by the timer, but instead the timer notifies the running
thread, which must switch to the scheduler task. This require less locking
mechanisms at the low level, which may be faster, because locking takes
time continuously, and other reasons. OTOH it's less smooth unless you
really insert a lot of those "if (time_expired) switch_threads();"
statements in every place that may take a non-small amount of time to run.

Quote:
> Does anybody know, if the Python and Perl Thread implementations are similar
> to the ruby Thread implementation??

Perl uses a different model. I think it's using one interpreter per
thread, possibly using kernel threads. I don't know the details.

________________________________________________________________
Mathieu Bouchard                   http://hostname.2y.net/~matju



Sun, 04 Jul 2004 23:48:18 GMT  
 A question on Ruby Threads
-----BEGIN PGP SIGNED MESSAGE-----


Quote:




>>> hello

>>> this is more of a general question on Ruby Threads. I have never used
>>> threads in any language until now, so I am a complete newbie to this
>>> topic. (have read something about threads in a bad java book, but this
>>> didn't help me with the following questions)

>>> Does anybody know, if the Python and Perl Thread implementations are
>>> similar to the ruby Thread implementation??

>Python uses the same portable-thread-type scheme as Ruby. I know nothing
>of Perl's threading mechanisms, or even if it has them.

- - Perl5.6 and higher had an experimental interface to native
  threads on Unix boxes. It didn't really work reliably, but
  if you avoided certain operations it was stable. I would say
  it was useful for learning about threads, but you'd be a
  fool to run it in a production app.

- - I'm not really entirely positive about what's happening in
  the newest perl, but the old thread model is being ditched
  and there's a new one where instead of data being shared
  by default you have to explictly share the data. It's called
  ithreads I think and I'm not sure of it's status.

- - Booker C. Bense

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBPEWoqgD83u1ILnWNAQFOTQQAi1vDuo9GuUfxUw+/5m8HwURnzDSStPAO
9gP4SG9tCRwkPbY/st3tscQKVmjCPQB9sPU+K3GC0t4/WBqS+iV3554dvRbXWUEd
qfYVCWN8rYVEFL2btIT5I0djHu0h/gXepHTSXDSdEDiLQ3yvKbVDl1ikgiT9zybL
j5PxcHp8rFw=
=+AXi
-----END PGP SIGNATURE-----
--



Mon, 05 Jul 2004 00:22:02 GMT  
 A question on Ruby Threads
Tobias's humor holds a very important point.
At first blush threads are very attractive, they
seem to offer infinite convenience at no cost.

Be aware that there is no real cross-platform
thread implementation and that the behaviour of
threads among unices can be bizarrely different.

Event loops are better than threads.  John Ousterhout
may not have been a very good businessman, but he's
a brilliant computer scientist:

http://www.softpanorama.org/People/Ousterhout/Threads/tsld001.htm

Phil

Quote:

> Good luck! But watch out for those race conditions! ;-)
> (little thread humor.... I know, I'm a geek)



Mon, 05 Jul 2004 01:02:25 GMT  
 A question on Ruby Threads
Hi,

In message "Re: A question on Ruby Threads"

|> Yes, pthreads on Unix and the WIN32 threads on Windows.
|
|PThreads are not native threads. PThreads is a package created at MIT to
|faciliate portable threading model. Tthey are user-space threads
|(switched by the process itself, susceptible to full process-block on
|single thread blocking).

I guess pthread here means POSIX thread (means API), not the MIT
pthread implementation in particular.  Some incarnation of pthreads
are user level, others are kernel level, some mixed.

                                                        matz.



Mon, 05 Jul 2004 01:32:41 GMT  
 A question on Ruby Threads
Hi,

In message "A question on Ruby Threads"

|what exactly is a native thread?? (something using pthreads on linux??)

I meant thread library which is provided along with OS, i.e. pthreads
on many flavors of UNIX, Win32 threads on Windows.

|what is the advantage / disadvantage of the ruby approach to threads??

Ruby's is slow but portable.  It runs everywhere (even on plain DOS).

|are native threads faster??

In general, yes.

|Does anybody know, if the Python and Perl Thread implementations are similar
|to the ruby Thread implementation??

They are using native thread.  Python uses giant interpreter lock (I
think it still uses the global lock).  Perl uses per thread interpeter
struct.

                                                        matz.



Mon, 05 Jul 2004 01:32:41 GMT  
 A question on Ruby Threads


Quote:
> Event loops are better than threads.  John Ousterhout
> may not have been a very good businessman, but he's
> a brilliant computer scientist:

Oddly enough, having read partway through this, I don't
really disagree,  despite having a "every programmer a
threads programmer" attitude.  The event-driven paradigm
that Ousterhout advances here is similar to the ultimate
goal of much of the thread programming I do.  What this
presentation fails to take into account however, is that
for many applications, the programmer does not have the
luxury of an API that allows  her to register all the
events in which she is interested.  In creating an elegant,
event-driven multithreaded application, the programmer
usually has to first set up an infrastruture that exposes
various system states as events.  Only then can handlers be
registered for those events.

What Ousterhout says about thread programming being
difficult is (unfortunately) quite true.  Thread
programming doesn't have to be that hard though.  The
problem here is that, despite how long threads have been
with us, much of the thread programming that is taught and
practiced is still at an unnecessarily low level.
Multithreaded programs are still intricate masses of
heavily interdependant threads and complex locking schemes.
 The design patterns, idioms, and paradigms that can
greatly simplify thread programming have barely begun to
propagate into the various language communities.

I was pleasently surprised when I found that
implementations of certain basic muiltithreading patterns
were included in the Ruby standard library.  This is more
than can be said for many languages.  But it's still not
nearly enough.  If more languages provided standard,
out-of-box implementations of things like synchronized
objects, the Reactor pattern, and the Active Object
pattern, multithreaded programming probably wouldn't be
nearly the "black art" that it's currently regarded as.

- Avdi Grimm

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/



Mon, 05 Jul 2004 02:21:17 GMT  
 A question on Ruby Threads

Quote:

>Tobias's humor holds a very important point.
>At first blush threads are very attractive, they
>seem to offer infinite convenience at no cost.

>Be aware that there is no real cross-platform
>thread implementation and that the behaviour of
>threads among unices can be bizarrely different.

>Event loops are better than threads.  John Ousterhout
>may not have been a very good businessman, but he's
>a brilliant computer scientist:

>http://www.softpanorama.org/People/Ousterhout/Threads/tsld001.htm

Will Ruby 2.0 have event loops?

Another Ruby 2.0 question:
Will it keep the current threading model and add native threading as a
module? (I would vote for this, since native threading doesn't work
everywhere - for example, would native threads work on a PalmPilot?)

Phil



Mon, 05 Jul 2004 02:18:55 GMT  
 A question on Ruby Threads


Quote:

>> Event loops are better than threads.  John Ousterhout may not have been
>> a very good businessman, but he's a brilliant computer scientist:
[...]

Why do you say that not every API has access to event-based programming?
What language (aside from Microshaft POS languages) do you know of that
doesn't implement select()? There's more than one way to skin a cat where
that's concerned, and I remember a very long thread a couple months ago
on this list about using continuation variables instead of threads in certain spots.
Resourceful, aren't they? ;-)

Part of the myth here, and I speak as a recent college graduate, is that
threads are not taught in depth enough, with the time that they deserve.
Thread synchronization is taught with the attitude, "Yeah, there's these
threads and you can synchronize them just like processes" (or at least,
that's how my prof. taught it). With a background like that, you can see
where the dilemma comes from. Not being familiar with the synchronization
primitives is not being familiar with threads. Period. This could
possibly be the cause of the exalted position some programmers put
threads in, but that's just my guess. I know monitors had my head
spinning for a little bit there :)

--
I sense much NT in you.
NT leads to Bluescreen.
Bluescreen leads to downtime.
Downtime leads to suffering.
NT is the path to the darkside.
Powerful Unix is.



Mon, 05 Jul 2004 03:30:55 GMT  
 A question on Ruby Threads

Quote:

>...

> Event loops are better than threads.  

That's not what Ousterhout said.

Quote:
> ... John Ousterhout
> may not have been a very good businessman, but he's
> a brilliant computer scientist:

Ousterhout admits that event loops are not a general purpose replacement
for threads:

http://www.softpanorama.org/People/Ousterhout/Threads/tsld011.htm
http://www.softpanorama.org/People/Ousterhout/Threads/tsld013.htm
http://www.softpanorama.org/People/Ousterhout/Threads/tsld014.htm

 Paul Prescod



Mon, 05 Jul 2004 04:18:51 GMT  
 
 [ 31 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Simple Ruby-Thread question.

2. Threads creating threads creating threads...

3. thread, threading, mutex modules and non-threading interpreters

4. C Extensions blocking all ruby threads

5. os-thread synchronize with ruby

6. Ruby-Gnome2 and thread-safety

7. problem with threading mysql queries in ruby

8. BUG: threads and ruby/tk

9. Ruby/Gtk and threads

10. Halting Ruby's threading

11. Threading the Ruby environment

12. Threading still broken in Win Ruby?

 

 
Powered by phpBB® Forum Software