From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA01376 for caml-redistribution@pauillac.inria.fr; Mon, 6 Mar 2000 14:10:26 +0100 (MET) Resent-Message-Id: <200003061310.OAA01376@pauillac.inria.fr> Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA22087 for ; Fri, 3 Mar 2000 19:17:08 +0100 (MET) Received: from julie.univ-savoie.fr (univax.univ-savoie.fr [193.48.120.32]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id TAA26346 for ; Fri, 3 Mar 2000 19:17:05 +0100 (MET) Received: from univ-savoie.fr (lama-d134.univ-savoie.fr [193.48.123.134]) by julie.univ-savoie.fr (8.9.3/jtpda-5.3.3) with ESMTP id TAA81953 ; Fri, 3 Mar 2000 19:16:52 +0100 (CET) Sender: raffalli@univ-savoie.fr Message-ID: <38C00196.C3AA1CE1@univ-savoie.fr> Date: Fri, 03 Mar 2000 19:16:54 +0100 From: Christophe Raffalli Organization: Laboratoire de =?iso-8859-1?Q?Math=E9matiques?=, =?iso-8859-1?Q?Universit=E9?= de Savoie X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686) X-Accept-Language: fr, en MIME-Version: 1.0 To: John Max Skaller , caml-list@inria.fr Subject: Re: GC + thread References: <38BBEA7A.BCC0B1E4@univ-savoie.fr> <38BDD0C9.D26E970@in.ot.com.au> <38BE34F7.1B4405E8@univ-savoie.fr> <38BFEBFB.50487A27@maxtal.com.au> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Resent-From: weis@pauillac.inria.fr Resent-Date: Mon, 6 Mar 2000 14:10:26 +0100 Resent-To: caml-redistribution@pauillac.inria.fr John Max Skaller wrote: > > Perhaps I didn't explain myself well. I understand there > is a problem with in_channel and out_channel. This same problem > can arise with Unix.descr files (although there is a rich enough > facility > to avoid this problem by always doing non-blocking operations?) > It is not really a "problem". It is just that they can help a GC collects blocked thread (see below). > I guess the same happens with Event.channels? > All what I said is only for Event.channels and no other types of channels. Perhaps I didn't explain myself well too ! > My question is really: isn't the scenario you describe > more general? Is there some way that your solution can be applied > to a wider class of resources than in/out channels? The point is to try to make the GC collect blocked threads. And the algorithm I described is needed and you do not need really more (or more exactly you can not hope for more because a GC can not be perfect) Let us examine how a thread can be blocked forever: - blocked on a channel (in/out or both): this can be solved by the extended GC. - blocked on a file: you can do nothing: the GC can not scan the outside world! - blocked on a mutex: If the thread never wakeup it means that someone forgotten to release a ressource. This is probably a bug of the program, it is not really necessary for the GC to care. - blocked on a condition: Same reasonning than for mutex. - blocked waiting for another thread: this is also probably a bug. but in this case it is probably OK for the GC to collect all thread waiting for a thread which can be itself collected. To extend the GC with the three last cases you can see that they are easely codable using in/out channels and get the proper behavior. Notice that coding with general channel (not in/out) would not lead to the proper behavior of the GC ! Let us do it for the join operation (waiting for another thread): You use an out channel for each thread where you send (broadcast) something as soon as you terminate. You use the in part of the out channel of a thread to wait for it. If a thread A is blocked waiting on another thread B which is "dead" for the GC. Then the GC will not scan the out channel and will detect that the first thread is dead two (no accessible pointer on the out channel). If another thread has a pointer on the in part of the out channel there is no problem. But if we did not make the in/out distinction, then the GC could not collect anymore the blocked threadv A. Conclusion: every thread should be considered by the GC as an out channel which is visible by the GC if the thread is alive. Waiting for a thread is considered as waiting on the in part of the channel. I think the mecanism I described is standard in language like pict, isn't it ? And it shoud (must) be in any language with threads and GC. -- Christophe Raffalli Université de Savoie Batiment Le Chablais, bureau 21 73376 Le Bourget-du-Lac Cedex tél: (33) 4 79 75 81 03 fax: (33) 4 79 75 87 42 mail: Christophe.Raffalli@univ-savoie.fr www: http://www.lama.univ-savoie.fr/~RAFFALLI