Date: Wed, 05 Aug 1998 20:07:48 -0400 From: "Daniel M. Eischen" <eischen@vigrid.com> To: shmit@kublai.com Cc: current@FreeBSD.ORG Subject: Re: Pthreads woes Message-ID: <35C8F3D4.167EB0E7@vigrid.com>
next in thread | raw e-mail | index | archive | help
I'm having similar problems with the tasking runtime of the
last customer release of GNAT (Ada). The GNAT runtime, when
an application uses tasking services, creates a couple of
threads (timer_server and interrupt_manager). Each Ada task
is its own thread. Each task also has its own mutex and CV pair
which are used for timed delays and event notification.
The problem occurs when trying to do a timed delay. The sequence
of events for a timed delay is very similar to what you show:
lock thread_mutex
wait for signal (cond_signal)
unlock thread_mutex
I'm in the process of debugging the problem, but it seems
that a SIGBUS or SIGSEGV is being generated when the thread
is signaled. The thread being awoken is receiving the (UNIX)
signal, not the signaling (cond_signal) thread. Ada handles
SIGBUS/SIGSEGV as Storage_Error exceptions, which is what
the GNAT runtime is seeing. It could be a pointer out of
whack in the threads library, perhaps in the process of queueing
and dequeueing threads waiting on CVs and mutexes. The code
looks correct though. I've added some _thread_sys_write
statements to the mutex and CV routines, but haven't found
the problem.
I've modified uthread_cond_timedwait as follows:
/* Unlock the condition variable structure: */
_SPINUNLOCK(&(*cond)->lock);
sprintf (s, "pthread_cond_timedwait, waiting...");
_uthread_sys_write (2, s, strlen (s));
/* Schedule the next thread: */
_thread_kern_sched_state(PS_COND_WAIT,
__FILE__, __LINE__);
sprintf (s, "pthread_cond_timedwait, awoken");
_uthread_sys_write (2, s, strlen (s));
/* Lock the condition variable structure: */
_SPINLOCK(&(*cond)->lock);
The thread (Ada task) calling this successfully goes to
sleep - you can see the "waiting..." mesage. You can even
see the mutex (as passed in to pthread_cond_timedwait())
being released and taken by another thread. But when the
sleeping thread is signaled (via cond_signal), a SIGBUS or
SIGSEGV is generated which gets sent to the sleeping thread.
The "awoken" message is never displayed.
I'm using 3.0-current as of 5 days ago. Using a libc_r from
a -current before the April spinlock/signal changes works. I've
tried creating a simple C program to duplicate the problems, but
can't reproduce it.
Normally, I'd spend some more time trying to debug the problem
before reporting it, but as long as someone else is having problems
also...
> I'm working on a program that spawns a bunch of threads in a pool, each
> of which sits on a condition variable. The main thread waits for
> a RADIUS request on a socket, it signals the condition variable on one
> of the threads in the pool.
>
> The sequence of events is:
>
> main
> ----------------------
> spawn threads
> loop {
> lock thread mutex
> wait for packet
> unlock mutex
> send signal to thread
> }
>
> threads
> ----------------------
> loop {
> wait for signal
> do RADIUS crap
> }
>
> The mutex in question is the same one as used by pthread_cond_wait.
>
> The problem is that I have to wake up the same thread /twice/ before
> it answers a request (IOW, pthread_cond_signal is called twice before
> the thread wakes up and `does RADIUS crap').
>
> I haven't been able to reproduce this in something that isn't so
> complicated (but I can give the full source to anyone who's interested),
> but I was hoping someone might be able to tell me off-the-bat if it's
> a known problem in some instances (or that it's a problem at all).
>
> If not, I'll see what I can do to make the test simpler.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35C8F3D4.167EB0E7>