Re: Some findings (was Re: Design hole in nptl (and more general in POSIX threads))

DragiĹĄa Durić <[email protected]> writes:
>   Next, I implemented PauseThread() signal handler (as was advised by
> Jim Blandy and very similiar to Boehm GC technique) for SIG39 and there
> I set tos (top of stack). SA_SIGINFO signal handler gave me registers in
> ucontext and there is esp field. Modula-3 garbage collector is
> conservative and it scans all registers and stack area of suspended
> threads for maybe-a-traced-heap-reference.

About a week ago I sat down to write an explanation of how using
signals to pause mutator threads fit in with the other deadlock
avoidance conventions, but ended up finding a serious problem
instead.

If you pause mutator threads until collection is complete, without
regard to what code those mutator threads are executing, then you may
pause a mutator thread while it is in some C library call, holding
locks that protect the malloc heap, or a stdio buffer, or something
like that.  If your collector then tries to call malloc, or write to
that stdio file, then it'll block trying to acquire a lock held by one
of the threads it has stopped.

You could work around this by being very strict about what resources
the collector tries to use.  If your collector never calls malloc
(perhaps it calls mmap itself directly), then it can't hang trying to
get malloc's mutex.

If I'm reading Boehm's code right, it looks like that is what he does:
he uses GC_scratch_alloc for growing the collector's internal
structures, which calls GET_MEM, which is usually GC_unix_get_mem,
which calls sbrk or mmap.

Restricting the collector to async-safe functions should be good
enough --- think of the collector as running on the signal handler's
behalf.

(For my precise collector, I think I have enough information to do
something less restrictive.)