Andres Kroonmaa wrote:
> Funny you say so. I just looked into linuxthreads sources and find that
> mutex_unlock indeed attempts to restart suspended thread if there are
> any blocked threads on given mutex. To do so, suspended thread is sent
> signal with kill(). So, whether thread switch happens depends on how
> kernel handles kill(). If it delivers it immediately, then thread switches too,
> if kernel just enqueues signal, then unlock returns fast.
linuxthreads uses RT signals for mostly everything. It does not make the
calling thread switch.
On Linux signal delivery is a rather fast IPC primitive.
> Yes, in linux thats true. Threads sit in linkedlist and cond_signal pops top
> one out of list. In addition, cond_signal also delivers literal kill() to popped
> thread, so thread switch may happen at cond_signal time too, before mutex
> is unlocked. If I know correct, then in linux threads are fullblown processes,
> and their switch is not much different from process switching. Will linux
> process switch task if one sends kill() signal to another?
linuxthreads are kernel threads. very similar to fullblown processes
except that they share the full context except for the pid and signal
queues.
> no, no optimisations are done here. kill signals are sent left&right. If thread
> restarts before mutex is released, it spins on it and if still can't acquire,
> suspends back again. Another kill will be delivered at unlock time. So in
> worst case, there are few ping-pong switches between threads in real fast
> succession. And alot of signals flowing.. didn't know that.
This confirms my suspicion that for our use it would be better to signal
outside the mutex, with an additional signal per select/poll loop to
break deadlocks (extremely unlikely to happen however).
> thats nice. I dunno why, but I had faint memory that in Solaris this had
> some quirk that made be drop this idea some time ago...
Sounds unlikely. pipes is one of the most fundamental IPC primitives in
UNIX, and unreasonable delays in pipes would impact performance
negatively in very many operations.
Anyway, the pipe "signal" is not critical. We surive even if it gets
lost, the only effect is a temporary I/O pause until select/poll timeout
or some external activity.
Regards
Henrik
Received on Sat Jan 04 2003 - 07:57:32 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:19:05 MST