[M3devel] [M3commit] CVS Update: cm3

[Jay K]

Right, oops, sorry, obvious error on my part  to leave the unlock order the same.
I don't know what rework LockHeap needs though. Maybe there is a problem with it allowing recursion?
i.e. ForkPrepare should assert that the lock count is 1?

 - Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sun, 9 Jan 2011 05:27:20 -0500
> To: hosking at cs.purdue.edu
> CC: jkrell at elego.de; m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>
> Jay,
>
> In order to support AtForkPrepare I think we will need to rework LockHeap.
> I'm working on it now.
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
> On Jan 9, 2011, at 4:52 AM, Tony Hosking wrote:
>
> > Jay, don't you need to order your unlocks in AtForkParent in reverse order to AtForkPrepare?
> > That means you'd need to UnlockHeap before unlocking the other mutexes.
> >
> > On Jan 9, 2011, at 4:35 AM, Mika Nystrom wrote:
> >
> >> Jay did you expect this to fix things?
> >>
> >> I'm still seeing the same problems...
> >>
> >>
> >>
> >> Jay Krell writes:
> >>> CVSROOT: /usr/cvs
> >>> Changes by: jkrell at birch. 11/01/09 03:36:
> >>> 46
> >>>
> >>> Modified files:
> >>> cm3/m3-libs/m3core/src/thread/PTHREAD/:
> >>> ThreadPThread.m3
> >>>
> >>> Log message:
> >>> LockHeap later in ForkPrepare, try to f
> >>> ix deadlock with mutex initialization
> >
>