Re: [Caml-list] Thread behaviour

[Romain Bardou <romain.bardou@inria.fr>]

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,

-- 
Romain Bardou