Warren Toomey <wkt@tuhs.org> writes:
>Sorry Andy, we haven't had time to look. But Gabriel also is worried
>that there are no real spinlocks around the hash functions in
>lib/hash.c. Could this be munging the messages and/or their handling?
No; the server is single threaded.
>Gabriel has started to put in the userland spinlock code, so we will
>report if it helps.
>Any other userland synchronisation areas we should worry about?
Making the whole C library thread safe is a pretty big step. I'd
stabilize the system in its single threaded mode first, then circle
back if needed to make the library (or any parts thereof) thread safe.
For the servers which are indeed multi-threaded (ABC with filesystems,
for instance) there is explicit use of mutexes when needed, and you
definitely need to make those mutexes work for SMP.
If worry about the use of the hash data structure within the kernel,
then the hash data structures hang off of kernel data structures, and
the mutexing at the kernel data structure is intended to make the
use of the hash structure safe. Remember, the kernel is preemptive,
so a lot of the race condition scenarios have already been exercised
even without SMP.
Andy
Received on 24 Feb 2004 20:14:35 GMT
This archive was generated by hypermail 2.1.8 : Tue Sep 26 2006 - 09:03:12 PDT