<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Texto sin formato Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Texto de globo Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
mso-fareast-language:EN-US;}
span.TextosinformatoCar
{mso-style-name:"Texto sin formato Car";
mso-style-priority:99;
mso-style-link:"Texto sin formato";
font-family:"Calibri","sans-serif";}
span.TextodegloboCar
{mso-style-name:"Texto de globo Car";
mso-style-priority:99;
mso-style-link:"Texto de globo";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="ES-CO" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoPlainText"><span lang="EN-US">Hi:<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">I don't think so, that's precisely why the locking level notation was invented by Trestle’ authors to cope with that complexity in the code, this allowed Trestle to be highly efficient for multiprocessors machines
(among other things we need to look again for readers and writers efficiency). These two pieces of software were ESCed by Nelson and others. In that side Nelson said about this was a mistake in Java programming language design, because of the difficulty of
reasoning about concurrency properties as seen in ESC experiments. If I may say add, Algol like languages excel in intelligibility, something other language families didn’t make too much effort to support.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">In any case, I’m not for this change so don’t make me do a second attempt to return to this forum
</span><span lang="EN-US" style="font-family:Wingdings">J</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">Thanks in advance<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><span lang="ES" style="mso-fareast-language:ES-CO">-----Mensaje original-----<br>
De: Rodney M. Bates [mailto:rodney_bates@lcwb.coop] <br>
Enviado el: Martes, 08 de Julio de 2014 02:20 p.m.<br>
Para: m3devel<br>
Asunto: [M3devel] Fwd: Re: Fwd: Fork bug</span></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Resent after 24 hours:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">While we are working on MUTEX, I would like to propose making them what I believe is meant by a recursive mutex, that is, one thread can lock multiple times, the mutex being released only when the number of unlocks catches up with the
number of locks.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I don't remember the details off the top of my head, but there is a place in Trestle where you have to acquire a MUTEX but it is very difficult or impossible to know whether different code on the same thread already has done so. The
different code isn't under your control either. Some runtime scheme to figure it out dynamically would be tantamount to, but messier than, just having a recursive MUTEX.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I recall there are other places as well where similar problems arise.<o:p></o:p></p>
<p class="MsoPlainText">It would greatly simplify things when needed.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">The only disadvantage I can think of is there might be a case where runtime detection of a second lock attempt by the same thread would help find a bug. Maybe the RTS could have a way of setting the behavior of a specific MUTEX.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">On 07/03/2014 02:28 PM, Tony Hosking wrote:<o:p></o:p></p>
<p class="MsoPlainText">> I wonder if we should not move to a surrogate parent model to make this cleaner in general?<o:p></o:p></p>
<p class="MsoPlainText">> Since fork is (or should be) only used in service of creating a new process (i.e., fork + exec) then this technique would save us a lot of grief.<o:p></o:p></p>
<p class="MsoPlainText">> Thoughts?<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">> In the surrogate parent model, a program forks a child process at initialization time. The sole purpose of the child is to serve as a sort of "surrogate parent" for the original process should it ever need to fork another child. After
initialization, the original parent can proceed to create its additional threads. When it wants to /exec/ an image, it communicates this to its child (which has remained single-threaded). The child then performs the /fork/ and /exec/ on behalf of the original
process.<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">> Begin forwarded message:<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>> *From: *Peter McKinna <peter.mckinna@gmail.com <o:p></o:p></p>
<p class="MsoPlainText">>> <<a href="mailto:peter.mckinna@gmail.com"><span style="color:windowtext;text-decoration:none">mailto:peter.mckinna@gmail.com</span></a>>><o:p></o:p></p>
<p class="MsoPlainText">>> *Subject: **Fork bug*<o:p></o:p></p>
<p class="MsoPlainText">>> *Date: *July 2, 2014 at 10:30:24 PM EDT<o:p></o:p></p>
<p class="MsoPlainText">>> *To: *Antony Hosking <hosking@cs.purdue.edu <o:p></o:p></p>
<p class="MsoPlainText">>> <<a href="mailto:hosking@cs.purdue.edu"><span style="color:windowtext;text-decoration:none">mailto:hosking@cs.purdue.edu</span></a>>><o:p></o:p></p>
<p class="MsoPlainText">>><o:p> </o:p></p>
<p class="MsoPlainText">>> Hi Tony,<o:p></o:p></p>
<p class="MsoPlainText">>><o:p> </o:p></p>
<p class="MsoPlainText">>> That fork bug on posix doesn't appear to be fixed, so just to recap the problem. In the threadtest program if you have a bunch of threads creating mutexes and having them collected then get a thread that does a few forks what can
happen is that the child executes atforkchild as I think the first thing it does which calls initwithstackbase which does an allocation and possible collection. Unfortunately the weaktable from the parent may be non empty and this is the only thread executing.
It calls the cleanup of those mutexes of nonexistant threads some of which may be locked. If they are locked then pthread_mutex_destroy returns ebusy. Then the child exits with the abort in pthread_mutex_delete.<o:p></o:p></p>
<p class="MsoPlainText">>> Whether the abort is needed I dont know. In this case the error can be safely ignored. One could try to see if the owner of the mutex is still alive and not abort in that case. Otherwise if one is sure the child is going to do an
exec almost immediately then disabling the collector in atforkchild could work.<o:p></o:p></p>
<p class="MsoPlainText">>> In the broader picture anything thats got a weak ref still active could cause problems if one thread does a fork. The weak callback could do anything.<o:p></o:p></p>
<p class="MsoPlainText">>> Anyway I dont know what the fix is.<o:p></o:p></p>
<p class="MsoPlainText">>><o:p> </o:p></p>
<p class="MsoPlainText">>> Peter<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">--<o:p></o:p></p>
<p class="MsoPlainText">Rodney Bates<o:p></o:p></p>
<p class="MsoPlainText"><a href="mailto:rodney.m.bates@acm.org"><span style="color:windowtext;text-decoration:none">rodney.m.bates@acm.org</span></a><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
</div>
</body>
</html>