sem_wait() is a cancellation point in libkse?
eischen at vigrid.com
Mon Jan 19 22:02:15 PST 2004
On Tue, 20 Jan 2004, Craig Rodrigues wrote:
> I am trying to learn about pthread cancellation points,
> and am reading "Multithreaded Programming with PThreads" by
> Bil Lewis. In chapter 10 of this book, it states
> that sem_wait() should be implemented as a pthread
> cancellation point.
> I am not sure that sem_wait() is implemented as
> a cancellation point in libkse.
> I looked again at some of the Linux NPTL tests
> which I ported to FreeBSD:
> The tst-cancel12 test seems to be failing.
> In this test, a thread is spawned with
> pthread_create(), and then soon after
> pthread_create(), pthread_cancel() is called
> on this thread.
> Inside the thread, sem_wait() is called.
> The test is expecting that the thread should
> immediately exit at the sem_wait() call because
> sem_wait() should be a cancellation point.
> However, the thread does not exist after calling
> sem_wait(), so the test fails.
> I see that in libkse's thr_sem.c, that there
> is a _sem_wait() which looks like it is doing
> cancellation stuff, but it doesn't
> seem to be working.
> Am I misunderstanding how this should work?
libc uses strong symbols for sem_wait which override
the weak symbols that libpthread is using. The sem_wait
in libc isn't a cancellation point yet. I think the
sem_foo stuff in libc should be refactored to just make
the system calls (like semop/semctl) and not know about
waiting threads. The threads libraries can wrap them
if they want to provide cancellation points and faster
userland thread switches for (process scope) thread
In short, we know about this.
More information about the freebsd-threads