I have created two child thread using main thread- child1 and child2.
Now child 2 has stopped along with main thread. They stopped executing
or proceeding. Only child 1 is proceeding. After child1 finishes…child2
starts, and then main. I want both child1 and child 2 run parallely, how
to achieve that? any pointers/suggestion?
On Tue, Aug 28, 2012 at 4:01 PM, ajay paswan [email protected]
wrote:
I have created two child thread using main thread- child1 and child2.
Now child 2 has stopped along with main thread. They stopped executing
or proceeding. Only child 1 is proceeding. After child1 finishes…child2
starts, and then main. I want both child1 and child 2 run parallely, how
to achieve that? any pointers/suggestion?
Normally they run in parallel - there are some limitations on MRI
though. What Ruby do you use and what do your threads do?
Kind regards
robert
Thank you very much for replying quick!
Normally they run in parallel - there are some limitations on MRI
though.
MRI?
What Ruby do you use and what do your threads do?
Ruby version:
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]
Am doing WEB GUI testing using watirweb.
On Tue, Aug 28, 2012 at 7:19 AM, ajay paswan [email protected]
wrote:
Ruby version:
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]
This version of Ruby (also known as MRI, Matz Ruby Interpreter, and also
YARV, Yet Another Ruby VM) does not support parallel multithreading and
instead uses a Global Interpreter Lock (or Global VM Lock) which only
allows one thread to run at a time.
Many operations release the GIL, such as I/O and certain uses of
cryptographic primitives. However, if you’d truly like to do parallel
computation in Ruby, it’s not possible on this version of Ruby.
You need to use a Ruby implementation without a GIL that supports
thread-level parallelism, such as JRuby or Rubinius.
Tony A. wrote in post #1073605:
On Tue, Aug 28, 2012 at 7:19 AM, ajay paswan [email protected]
wrote:Ruby version:
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]This version of Ruby (also known as MRI, Matz Ruby Interpreter, and also
YARV, Yet Another Ruby VM) does not support parallel multithreading and
instead uses a Global Interpreter Lock (or Global VM Lock) which only
allows one thread to run at a time.Many operations release the GIL, such as I/O and certain uses of
cryptographic primitives. However, if you’d truly like to do parallel
computation in Ruby, it’s not possible on this version of Ruby.
Could you tell me the version’s which allow multithread parallelism?
and why did they decided to not include multithread parallelism? because
I think its a facility… if I am not wrong? and with time technology
should give more facilities… any specific reason… really want to know.
You need to use a Ruby implementation without a GIL that supports
thread-level parallelism, such as JRuby or Rubinius.
Will I face any problem if I use JRuby or Rubinius… any compatibility
issues?
Hi All,
Sorry for jumping in, but Tony, can you please explain what the idea is
behind having Threads implemented and not allowing them to be executed
in
parallel? Thanks in advance.
Andriy
Apart from getting the above answers… I would like to point out that:
If I do:
sudo update-alternatives --config ruby
1 ↵
[sudo] password for use:
There are 2 choices for the alternative ruby (providing /usr/bin/ruby).
Selection Path Priority Status
0 /usr/bin/ruby1.8 50 auto mode
1 /usr/bin/ruby1.8 50 manual mode
- 2 /usr/bin/ruby1.9.1 10 manual mode
And even I select 1.8, it has the same problem… I cannot run both
thread parallelly!
On Tue, Aug 28, 2012 at 11:11 AM, ajay paswan [email protected]
wrote:
And even I select 1.8, it has the same problem… I cannot run both
thread parallelly!
There are only four Ruby implementations that can run threads
concurrently (which is what you are looking for):
- JRuby - always has had concurrent threads because the JVM has
concurrent threads - Rubinius - switched to concurrent threading a bit over a year ago
- MacRuby - switched to concurrent threading some years ago
- IronRuby - always has had concurrent threads because the .NET CLR
has concurrent threads
Of these, Rubinius is closest to “100%” compatible with regular Ruby,
since it also supports C extensions. JRuby arguable has the most
stable thread implementation, since it’s the JVM’s threads and they’ve
been parallel for over a decade. MacRuby only works on OS X. IronRuby
only works on .NET platforms, but I think it works ok on Mono.
You cannot get concurrent threads on any version or build of standard
Ruby (“C Ruby”, “MRI”, “MatzRuby”) at this time. Pick something else.
- Charlie
On Tue, Aug 28, 2012 at 6:11 PM, Andriy A. [email protected]
wrote:
Sorry for jumping in, but Tony, can you please explain what the idea is
behind having Threads implemented and not allowing them to be executed in
parallel? Thanks in advance.
You can still get enough concurrent execution for a large class of
applications that way. This is true namely for applications which do
a lot IO. You can try it out yourself:
$ ruby19 -e ‘5.times.map {|t| Thread.new(t) {|id| 10.times {|i| printf
“th-%p: %5d\n”,id,i}}}.each(&:join)’
th-0: 0
th-0: 1
th-1: 0
th-2: 0
th-0: 2
th-3: 0
th-0: 3
th-2: 1
th-4: 0
th-1: 1
th-2: 2
th-0: 4
th-3: 1
th-4: 1
th-2: 3
th-1: 2
th-3: 2
th-0: 5
th-4: 2
th-3: 3
th-1: 3
th-2: 4
th-4: 3
th-0: 6
th-3: 4
th-2: 5
th-1: 4
th-0: 7
th-4: 4
th-3: 5
th-1: 5
th-2: 6
th-0: 8
th-3: 6
th-4: 5
th-1: 6
th-0: 9
th-2: 7
th-3: 7
th-1: 7
th-4: 6
th-2: 8
th-1: 8
th-3: 8
th-2: 9
th-4: 7
th-1: 9
th-3: 9
th-4: 8
th-4: 9
Also, this approach allows to have multithreading on a platform which
does not support threads out of the box. Granted, these are rare
nowadays - that was more important in the early days.
Kind regards
robert
kindly clear me … my confusion over why people has stopped
multithreading in ruby?
and… how to know which ruby supports multi threading?
On Tue, Aug 28, 2012 at 9:11 AM, Andriy A.
[email protected]wrote:
Sorry for jumping in, but Tony, can you please explain what the idea is
behind having Threads implemented and not allowing them to be executed in
parallel? Thanks in advance.
By mapping Ruby Threads onto native threads, several threads can be
executing system calls in parallel. When a thread wants to do a system
call
in 1.9, it can explicitly release the GIL and allow other threads to
run.
The previous version of MRI used green threads and had lots of slowness
surrounding I/O due to the fact that it could only make one system call
at
a time. This was also a huge issue for things like database drivers.
On Tue, Aug 28, 2012 at 12:34 PM, ajay paswan [email protected]
wrote:
kindly clear me … my confusion over why people has stopped
multithreading in ruby?
Google is your friend
ruby gil
and… how to know which ruby supports multi threading?
See Charlie’s response above - clean list of implementations that
support
concurrent threads.
On Tue, Aug 28, 2012 at 1:00 PM, Peter Z.
[email protected]wrote:
Ruby 1.8 had green threads, which did work on threadless platforms, but
having green
threads doesn’t require one to abandon multicore support. For example,
Erlang
has both.
A minor nit: depending on who you ask, the phrase “green threads” is the
proper opposite of “native threads”. Systems that utilize native threads
for scheduling (e.g. the Erlang SMP scheduler) are probably not properly
described as “green threaded”. Prior to the SMP scheduler, Erlang could
be
described as green threaded.
Erlang’s creators prefer the phrase “process” for its concurrency
primitive, although it can generally be described as being
“microthreaded”
Robert K. писал 28.08.2012 21:31:
nowadays - that was more important in the early days.
It does not, at least not by itself. Ruby 1.9 requires a proper
pthreads
implementation, which means that you must provide a scheduler anyway.
Ruby 1.8
had green threads, which did work on threadless platforms, but having
green
threads doesn’t require one to abandon multicore support. For example,
Erlang
has both.
Tony A. писал 29.08.2012 00:07:
Erlang’s creators prefer the phrase “process” for its concurrency
primitive, although it can generally be described as being
“microthreaded”
I think that the term “userspace threads” works for any protected-mode
OS.
E.g DOS does not have explicitly defined userspace, but a scheduling
pthreads shim for DOS is effectively a green thread implementation, so
the
distinction is a bit meaningless there.
“Interpreter-defined threads” would also cover various RTOS’es running
in
environments where there is an OS/user code distinction, but no
userspace/kernelspace one, through it still does not work for DOS.
I want to draw attention to my question again, sorry for asking some
other things.
ajay paswan wrote in post #1073608:
Apart from getting the above answers… I would like to point out that:
If I do:sudo update-alternatives --config ruby
1 ↵
[sudo] password for use:
There are 2 choices for the alternative ruby (providing /usr/bin/ruby).Selection Path Priority Status
0 /usr/bin/ruby1.8 50 auto mode
1 /usr/bin/ruby1.8 50 manual mode
- 2 /usr/bin/ruby1.9.1 10 manual mode
And even I select 1.8, it has the same problem… I cannot run both
thread parallelly!
On Tue, Aug 28, 2012 at 11:15 PM, ajay paswan [email protected]
wrote:
I want to draw attention to my question again, sorry for asking some
other things.
Try using RVM:
Once RVM has been installed, you can do:
rvm install jruby
or
rvm install rbx