Re: [Caml-list] Smart ways to implement worker threads

[Goswin von Brederlow <goswin-v-b@web.de>]

Rich Neswold <rich.neswold@gmail.com> writes:

> On Thu, Jul 15, 2010 at 11:02 PM, Goswin von Brederlow <goswin-v-b@web.de>
> wrote:
>
>     Rich Neswold <rich.neswold@gmail.com> writes:
>
>     Thanks. That is about what I got so I do seem to understand the
>     differences right.
>
>     For my use case this would then come down to implement solution 3 with
>     channels instead of my own queues. Well, channels are thread safe queues
>     just by another name. I think I see now how they make the code simpler
>     to write.
>
>
> Channels are a thread-safe communication channel of depth one (i.e. you can
> only pass one item at a time.) The channel is a primitive that allows reliable

Urgs, so what happens if I call "sync (send ...)" twice without the
other end calling recieve? Lets test:

let ch = Event.new_channel ()

let reciever () =
  for i = 0 to 10 do
    Printf.printf "recieved %d\n" (Event.sync (Event.receive ch));
    flush_all ();
    Unix.sleep 2;
  done

let _ =
  ignore (Thread.create reciever ());
  for i = 0 to 10 do
    Printf.printf "sending %d\n" i;
    flush_all ();
    Event.sync (Event.send ch i);
    Unix.sleep 1;
  done

% ocamlopt -thread -o foo unix.cmxa threads.cmxa foo.ml && ./foo
sending 0
recieved 0
sending 1
recieved 1
sending 2
recieved 2
sending 3
recieved 3
...

So the send blocks until the event is recieved. That certainly isn't
helpfull for me. One could say I want asynchronous remote function calls
(and returns).

> synchronized communication between threads. The Reppy book describes in later
> chapters how to use the channel primitive to build up queues and other, more
> complicated constructs (like RPCs and multicasting to many processes.)
>
> In fact, you might use the RPC ideas to pass your checksumming requests to
> worker tasks and receive the results.

Yeah. But then why not build it around the simple Mutex and Condition
modules instead of Event? At first glance the blocking aspect of Events
seem to be more of a hindrance than help.


I find it odd that there is no Threaded_Queue module, a thread save
version of Queue with 2 extra functions:

val wait_and_take : 'a t -> 'a

   wait_and_take q waits for the queue q to be not empty and removes and
   returns the first element in queue q. Raises Empty when the queue is
   closed.

val close : 'a t -> unit

   close q closes the queue and wakes up waiting threads.


MfG
        Goswin