Re: PostgreSQL
[email protected] Fri, 3 Feb 2006 12:07:03 +0100
| Newsgroups | gmane.os.netbsd.devel.performance |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Feb 02, 2006 at 06:16:30PM +0000, Edward B. DREGER wrote: > >Date: Thu, 2 Feb 2006 04:15:42 +0100 > >From: joerg@... > > >It depends *very* strongly which mechanisms you use. If all you need and > >want is a block mutex, you ultimately have to call the kernel for > >synchronistation anyway -- both in forking and 1:1 threading. > > Not necessarily. Store the mutex in a SHM segment, then perform the > mutex operations entirely in userland. Pure spinning is not an option for efficiency, esp. if the number of threads/prcoesses is larger than the number of CPUs and the blocking conditions can hold for more than one time slice. Most mutex implementations are at least somewhat adaptive, if the environment allows it. E.g. it spins a number of times trying to get hold of the mutex, afterwards it tells the kernel to block on it. This needs some care for the exit case as well, but is possible to implement. But once again, MT vs. MP doesn't make any difference here. [snip example] > Or am I missing something? You are effectively implementing Token Ring :-) There are different mechanisms for passing lock ownership, e.g. compare a classic mutex with DragonFly's token primitive. They all have different performance characteristics, but none is free. Trading bus locked operations for round robin operations + spinning is almost always a bad deal though, I'd say. Joerg