how about using a GLib::Timeout instead of threads? threads can gum
up the works if you’re not careful…
require ‘glib2’
repeat = true
GLib::Timeout.add(1000){
p ‘=>A’
true ? repeat : false
}
GLib::Timeout.add(1000){
p ‘=>B’
true ? repeat : false
}
the true or false at the end of each block tells the timeout whether
to repeat the block or stop - true repeats, false stops. the argument
to the #.add method is the amount of time to wait before repeating.
Actually my original problem
is much more complicated and I just simplified it to ask in this forum.
Then apparently you did not abstract the problem properly. Before we
jump to solutions can you explain why you say you must use threads?
What is the real problem you are trying to solve?
I just found the ConditionVariable class, and it seems it is the key to
implement such cooperation between threads.
Please help review my code below. Let me know if I did anything wrong.
The whole approach is too complicated for the problem to be solved (see
above).
Thanks Robert and Jake. I must use threads. Actually my original problem
is much more complicated and I just simplified it to ask in this forum.
I just found the ConditionVariable class, and it seems it is the key to
implement such cooperation between threads. I wrote a new version (see
the code below), but there is still one problem:
after thread A completes its job, it needs to wake B and then put
itself into sleep. What if B runs too fast and B calls
ConditionVariable.signal before A calling ConditionVariable.wait?
I want to use multi-threading + JRuby to achieve better performance.
My problem has a single input file that contains millions of lines. Each
line is the input of a time-consuming computing and will generate an
output result.
What in my mind is:
the main thread prepares N working threads, and put them into sleep
state.
the main thread open the input file and pass the file object to each
thread[:file]
the main thread send a “GO” command to all the working threads
each thread works in the below loop:
4.1 lock the mutex associated with the file object, read a line, and
then unlcok. if EOF is encountered, exit from the loop.
4.2 do the very time-consuming computing
4.3 put the result to thread.current[:result]
4.4 signal the main thread to pick up the result
4.5 go to sleep state (waiting for being waken up by the main thread)
the main thread works in the below loop:
5.1 go to sleep state until being waken up by one of the working
threads.
5.2 check all the working threads’ [:result] and extract them out and
do some aggregation.
5.3 for those threads whose result has been picked, send a signal to
let them proceed with the next line.
once all the working threads finish, the main thread output the
aggregated result.
the main thread open the input file and pass the file object to each
thread[:file]
the main thread send a “GO” command to all the working threads
Did you ever hear of blocking queues?
5.2 check all the working threads’ [:result] and extract them out and
do some aggregation.
5.3 for those threads whose result has been picked, send a signal to
let them proceed with the next line.
6. once all the working threads finish, the main thread output the
aggregated result.
This sounds like a very typical application of farmer worker. You
create two queues, one for tasks and one for results. Then you start
a thread which fetches results from the result queue and processes
them. Then you start a number of threads which read from the tasks
queue, process tasks and place results in the result queue. Finally
you use Thread#value to join on the result processor.