[ruby-talk:6392] Re: lots of Threads

On Thu, 16 Nov 2000  19:59:07 +0900, Hugh Sasse Staff Elec Eng wrote:
> On Thu, 16 Nov 2000, Dave Thomas wrote:
> > Hugh Sasse Staff Elec Eng <[e-mail]> writes:
> > 
> > > If I have an array to be filled with computationally heavy stuff, 
> > > I could use a load of Threads to populate it in parallel.  If I often
> > > have to re-populate it, I don't want to kill them all off and start
> > > them again.
> > 
> > But why would that be faster? Ruby threads can't take advantage of
> 
> I'm not sure that it would.  Certainly if I have to create and destroy
> lots of threads it will be lots slower...
> 
> > multiple processors, so unless filling the array also involves waiting 
> 
> OK, I had a vague feeling that it could not...

Unless you spread the work over multiple processes using fork instead
of threads, so the OS can distribute the Ruby instances over the
cpu's.

(META: would a pthread impl. of Ruby be a Good Thing[tm]?)

> > for I/O, I'd guess it would go slower with threads (as the old Coke ad 
> 
> The actual filling won't be using I/O but I will be shoving the contents
> of the array out to tape, after I have filled it, and I'm now wondering
> about the best way to tackle that producer-consumer problem.  Do I need
> a Mutex.synchronize to access the buffer, or will Thread.stop, athread.run
> give sufficient control?

Maybe the async producer/consumer example in
http:/www.xs4all.nl/~hipster/lib/ruby/semaphore is of any use? If you
elect to fork the processes the Semaphore class would have to use IPC
primitives, of course.

	Michel