From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id FAA00753; Tue, 13 Apr 2004 05:48:43 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id FAA00695 for ; Tue, 13 Apr 2004 05:48:42 +0200 (MET DST) Received: from herd.plethora.net (herd.plethora.net [205.166.146.1]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i3D3mdYM012917 for ; Tue, 13 Apr 2004 05:48:40 +0200 Received: from bhurt.plethora.net (bhurt.plethora.net [205.166.146.49]) by herd.plethora.net (8.11.6/8.10.1) with ESMTP id i3D3mVQ14402; Mon, 12 Apr 2004 22:48:33 -0500 (CDT) Date: Mon, 12 Apr 2004 23:54:52 -0500 (CDT) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: John Goerzen cc: caml-list@inria.fr Subject: Re: [Caml-list] Threading: Using and Building In-Reply-To: <20040413021536.GA969@complete.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 threading:01 python:01 qid:99 xgl:99 glance:01 gotchas:01 threads:01 ocaml's:01 mkstemp:01 forking:01 streaming:99 mpi:01 wrappers:01 mpi:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 264 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