Re: [Caml-list] Thread behaviour

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

On Mon, Sep 30, 2013 at 10:24:01AM +0200, Romain Bardou wrote:
> Le 29/09/2013 19:47, Chet Murthy a écrit :
> > 
> >> This is my situation. I don't care if the code runs on a single core
> >> (in fact, I hope it does), but I do want to use threads which are
> >> scheduled reasonably independently and reasonably fairly. My first
> >> example shows that one thread is effectively starved by the other
> >> thread.
> > 
> > Ah.  ok.  In this case, it's easier.  You just need to ensure that in
> > every loop,in every recursive function, there's a call to something
> > that yield()s, on every path.  It's that simple, and that icky.  But
> > then, if you have code that literally doesn't do anything that yields,
> > in a loop, it's compute-intensive, and -that- means you're not really
> > asking for concurrency, are you?
> > 
> > BTW, to your original question "why should the while loop affect
> > scheduling of f's thread": because there is a global operation
> > (scheduling) that needs cooperation from all threads in order to
> > execute.  And that requires explicit coding by the programmer.  Now,
> > the compiler -could- have inserted code to do the yield() (in some old
> > LISPms, it was done at every backward jump and return, I think).
> > 
> > I can't speculate as to why it wasn't done, but given that the goal of
> > ocaml's threads is concurrency, and not parallelism, it isn't common
> > (at least, in my experience) to write code that doesn't naturally
> > reach yield points frequently.
> 
> Unfortunately there is a huge class of such kind of code: code which
> uses libraries which do not yield. For instance, code which loads a DLL
> to communicate with hardware and which may block (or worse).
> 
> Cheers,

But that coulde would be external and you would release the global
lock before the blocking call. That's what e.g. Unix.write does. You
can have many threads that run in parallel. But only one at a time can
run ocaml code. All others can only run external code.

Also your example was bad because in real code you wouldn't
(shouldn't) have a busy loop that does nothing without at least a
yield in it. You assumed the flush would do something that triggeres
the scheduler but that doesn't seem to be the case if the buffer is
empty. Kind of makes sense. If there is nothing to flush then the call
just returns and nothing happens. Only when there is something to
flush it writes data, releasing the runtime lock and scheduling as a
side effect.

MfG
	Goswin

PS: Tip: Use Printf.printf "...%!"