[lug] q: multithreading on smp weirdness

[D. Stimits]

...
> 
> in my test app, i actually started out without the mmap
> function calls.
> i read somewhere that only 1 thread can be in the kernel
> at 1 time, & was wondering whether these mmap calls
> would cause these situations.

Couldn't tell you. One rule of thumb I have though is that things 
telling you "it shouldn't happen" are often wrong, and more theory than 
reality (or marketing). I would guess that the kernel version and thread 
library versions make a difference in behavior of multiple threads using 
one mmap'd memory block.

Most of the gotcha's for thread performance seem to fall into 3 
categories: (a) locking/synhcronizations (correctly implemented), (b) 
race conditions (incorrectly implemented locking/synchronizations), and 
(c) reentrant code eating up huge amounts of memory and/or time for 
thread-specific data when multiple threads hit the same function at the 
same time (note that that anything just plain thread-safe is not 
necessarily reentrant, and simple thread-safe locking is part of the 
correctly implemented synchronization).

If you profile, you'll see where the time is involved. See if one of the 
above 3 can in any way be related to the high time consumer.

D. Stimits, stimits AT comcast DOT net