Re: [Caml-list] Threading: Using and Building

[Brian Hurt <bhurt@spnz.org>]

On Mon, 12 Apr 2004, John Goerzen wrote:

> I know little about the GC issue, save that two other garbage-collected
> languages I have used (Java and Python) are able to work around it.

You can work around it, it just costs.  You end up implementing barriers- 
you can implement either read barriers or write barriers.  Write barriers 
would probably work better for Ocaml.  But basically, every modification 
of heap-allocated objects becomes a synchronization point with the GC.  
This will slow you down.

See:
http://www.amazon.com/exec/obidos/tg/detail/-/0471941484/qid=1081826531/sr=1-1/ref=sr_1_1_xs_stripbooks_i1_xgl14/104-8572163-9037569?v=glance&s=books

Or:
http://www.iecc.com/gclist/GC-faq.html

for more detail.

> You are correct that there are gotchas with multithreaded programming.
> However, there are some significant advantages.  One is that there is no
> need to establish lines of communication between one process and
> another -- that saves a significant amount of work right there.  It's
> also pretty easy in most systems to fire up a thread to run a function
> and check for (or be notified about) its result later.

The ability to have easy communication between threads is exactly the 
problem- you can have *accidental* and uncontrolled communication between 
threads- aka race conditions.  Badly applied synchronization can lead to 
deadlocks and livelocks.  Finding these to fix them can be royal pains.

I'd love to see Jocaml picked up again.  Enlist the type system to prevent 
these problems.

> 
> OCaml's design, minimizing the need to update variables, seems to lend
> itself nicely towards threadsafe programming.

Almost, but not quite.

> 
> I think that, overall, the fact that "some people can't do x correctly"
> is not a reason to make x unsupported in a language.  After all, we've
> seen programs all over that have buggy calls to open(2) -- especially
> those writing in /tmp.  That doesn't mean we have to turn off open(2) on
> our systems :-)

No, but we do provide mktemp() and mkstemp() functions to try and fix 
these problems.  And a number of features we do just drop outright- 
pointer arithmetic, for example.

There are better ways of doing things and there are worse ways.  If there 
is a better way that solves the problem, one that doesn't have the failure 
modes, then I'm all for it.  It's a trade-off- signifigantly fewer bugs 
for slightly less flexibility/ease.  

> 
> The alternatives are not necessarily easier anyway.  Forking and
> communicating over pipes involves the development of a streaming
> protocol and a way to send data across the pipe and decode it at the
> other end; existing objects cannot just be reused.  Synchronization can
> still be an issue, especially regarding open file descriptors, user
> interfaces, and disk files.  Deadlock can occur on pipes due to any
> number of reasons as well.

MPI gives you the wrappers around pipes.  Deadlocking can occur with 
mutexs and synchonized as well.  What can't happen is accidental sharing 
aka race conditions.  Jocaml solves the deadlocking/livelocking problems, 
but a) isn't maintained currently, and b) doesn't distribute across a 
network like MPI (no beowulf clusters).

> 
> > On Unix, you don't lose much doing multi-proccess (forks) instead of
> > threads.  Switching between processes in Unix isn't any slower than
> > switching between threads within a process.  But I've seen benchmarks
> 
> My primary concern here lies not with the performance difference between
> forking and threads in the general case, but rather the design
> differences.  For certain tasks, threading is just easier.  And it looks
> like OCaml has some serious limitations on threading.
> 

Having done both, I'd say MPI is easier to make *correct*, and Jocaml 
better still.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners