Squeak and threads

danielv at netvision.net.il danielv at netvision.net.il
Sat Dec 8 10:05:55 UTC 2001


You can also have many worker processes on the same shared queues, for
better resource utilization.
For example, suppose you want to get the all latest updates quickly. So
you want to d/l enough update files in parallel to saturate your ADSL
line, instead of getting them one at a time, as they get eaten by the
filein mechanism.

So you just make 10 copies of your d/l process, make them loop on
getting waiting for a request on the SharedQueue and performing it. If
the results handling is independent (like saving the update to the
updates directory) then you're done.

If you want to synchronize the handling of results (for example, to show
them in a single ordered list), have the workers all write to a single
shared queue, with a single reader.

This approach seems simpler than forking a process every time I get a
request, and it's worked for me for small hacks.

Daniel

Ned Konz <ned at bike-nomad.com> wrote:
> On Friday 07 December 2001 05:51 pm, Joe Graham wrote:
> 
> > But in any case my question is really what is the usage pattern?  I
> > understand that concurrency patterns just deal with communication between
> > two processes.  In the case of a thread, a parent and child process.  No
> > biggie.  But I would like to know more about how you would use a message
> > queue to accomplish this.  Or at least what a general usage pattern would
> > be to for example say implement a socket server capable of handling
> > concurrent requests. What would be an general design pattern (or
> > combination of patterns) in this case?
> 
> In Squeak threads, the concept of "parent" and "child" isn't too important. 
> Once the thread (Process in Squeak) is created, the relationship isn't 
> recorded anywhere.
> 
> The threads both continue to run.
> 
> One common design pattern is where a worker thread receives requests using a 
> SharedQueue. It blocks every time it does a "queue next" and there isn't 
> anything on the queue. Other threads that want to send it work to do use 
> writes to the queue.
> 
> For the concurrent server, you'd accept a new connection then fork a thread 
> to process it. Which might communicate with other threads using SharedQueues 
> or use resources serialized by Semaphores.
> 
> Other patterns (for instance, futures or promises, timeouts, thread joins, 
> etc.) are also possible using Semaphores as the primitive synchronization 
> mechanism.
> 
> -- 
> Ned Konz
> currently: Stanwood, WA
> email:     ned at bike-nomad.com
> homepage:  http://bike-nomad.com




More information about the Squeak-dev mailing list