On Thu, 16 Nov 2000, hipster wrote:

> 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 <hgs / dmu.ac.uk> 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...

I meant to say "repeatedly" here, hence my loop {...;Thread.stop} thing.

> > 
> > > 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]?)

So pthreads are processes to implement threads?  I think that could be
useful.  With Ruby's ability to re-define things the interface could be
kept the same as the built-in threads, just have a require...
> 
> > > 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

I will have a look at this, thank you.

> elect to fork the processes the Semaphore class would have to use IPC
> primitives, of course.
> 
> 	Michel
> 
> 
	Hugh