Re: [Caml-list] Thread behaviour

[Tom Ridge <tom.j.ridge+caml@googlemail.com>]

Hi Chet,



On 29 September 2013 17:46, Chet Murthy <murthy.chet@gmail.com> wrote:
>
>> OK, but this means that I can't think of OCaml code running in
>> different threads in a simple way - I have to consider the single
>> runtime lock at least (if I care about performance). So maybe the
>> question is: how should I understand the functioning of the single
>> runtime lock? For example, is starvation the only thing I need to
>> think about?
>
> Tom,
>
> Yaron's note made a careful distinction between two things:
> "concurrency" and "performance".  Let me explain a little more what
> he's getting at.

I sort-of understand what people mean by concurrency and
*parallelism*. Parallelism is e.g. trying to use multiple CPUs.
Concurrency is using constructs like threads etc. I think these words
aren't the best choice if trying to make this distinction, but that is
another issue.

>
> "concurrency" means writing programs using constructs that look like
> concurrent execution, for the purpose of .... well, for whatever
> purpose you'd like, but usually modularity.
>
>   --> in short, you don't care if your code's running on a single
>       processor -- you just want to -write- it with multiple threads

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.

>
>   [of course, here you care about -starvation-, hence the worry about
>   a tight loop with no possibility of suspension/"releasing the global
>   lock"; but let's set that aside, since it's a different concern
>   (even the LISPm, from what I remember, had issues here -- heck, so
>   do some JVMs, for GC)]

This is my concern! I want to understand what the issues are with
running code which uses multiple threads (from OCaml's Thread lib), on
a single core, given that there is a global lock.

>
> "parallelism" means exploiting hardware facilities to -run- code in
> parallel, usually for purposes of performance.
>
>   --> you care very much if your code "properly" exploits
>       SMP/multicore parallelism
>
> When you speak of "performance", I'm going to guess that you're really
> speaking of "parallelism" and not "concurrency".

No! I really am talking about concurrency. I am a firm believer that
message-passing is a very good way to utilize multiple cores. What I
want is to implement a message passing library, using multi-threading,
on a single core. I want to understand the issues that the single
runtime lock can cause when trying to do this. My naive idea is that
different threads execute as they would, say, using POSIX threads in
C. But the presence of the single runtime lock means that threads do
not behave like this (the code I started this thread off with
illustrates this). So how do they behave?

> If so, Ocaml's
> threads are not for you, nor are monadic programming constructs.  Not
> merely effectively, but -by- -construction- any threading system with
> a global lock can only use a single CPU.  You can get more than that
> from Ocaml, if Ocaml threads, spend a lot of time in C/C++ code that's
> CPU-intensive.  But I'm assuming that that's not what you're looking
> to do.

I didn't quite get that last sentence, but yes, I understand what you
are saying. I really do want to understand how to think about my code,
which uses OCaml Thread threads, on a single core, given that there is
a global lock. Now, it may be that to understand this there is no more
abstract approach than looking at the OCaml implementation. That is
fine. But it may be that people will say "the only problem you can
have is starvation, and you can avoid that by ensuring that each of
your threads calls Thread.yield() sufficiently often". That would be a
nice answer to have!

Thanks

T