[Gc] NetBSD pthreads support
hans.boehm at hp.com
Fri Feb 10 18:56:34 PST 2006
I'm sorry that this appears to have gotten dropped. I just noticed it
in trying to put 6.7 together.
I unfortunately still don't see why this makes sense. If NetBSD just
loses signals, that sounds like a bug, though a fairly common one. I
think there can only be one outstanding SIG_SUSPEND or SIG_RESTART
instance at a time, thus there shouldn't be a reason for it to get lost.
The GC_retry_signals mechanism is there to kind of handle that, though I
agree that it doesn't do well with lost SIG_RESTARTs. Why would waiting
on restarts fix this?
GC_stop_world needs to be synchronous, since it is incorrect to have
running threads while the collector runs. But it is perfectly fine to
have threads start late. There is no obvious reason to have another
round of acknowledgements and context switches.
> -----Original Message-----
> From: Tatsuya BIZENN [mailto:bizenn at visha.org]
> Sent: Wednesday, September 28, 2005 9:03 PM
> To: Boehm, Hans
> Cc: gc at napali.hpl.hp.com
> Subject: Re: [Gc] NetBSD pthreads support
> On 2005/09/29, at 4:45, Boehm, Hans wrote:
> > I think I'm fine with all of the changes, except probably the
> > introduction of GC_restart_ack_sem. This looks like it's trying to
> > fix
> > a possibly generic race condition, perhaps the one pointed
> out in the
> > thread "race condition when restarting threads", started by
> Ben Maurer
> > on July 3?
> Maybe, no. On NetBSD 2.x or 3.x, SIG_SUSPEND is sent but sometime
> suspend_handler() is not called, so sem_wait() in
> GC_stop_world() waits for sem_post() in suspend_handler() eternally.
> > Are you sure this is still necessary in 6.6?
> Yes. It's necessary in 6.6 too.
> > If so, is there any reason
> > to believe this is NetBSD-specific?
> Maybe, no. There is no reason for NetBSD-specific. Because,
> if GC_stop_world() should work
> synchronously(sem_wait()/sem_post() are used for this reason,
> aren't they?), I think GC_restart_world() should be same way too.
> But this code has some overhead. So if such deadlock is
> never happend on other platforms, it should be
> NetBSD-specific. Sorry but I didn't test on any other
> pthreaded platforms.
> Tatsuya BIZENN
More information about the Gc