* joerg@britannica.bec.de <joerg@britannica.bec.de> [060201 19:16] wrote:
> On Wed, Feb 01, 2006 at 06:58:04PM -0800, Alfred Perlstein wrote:
> > 
> > Also, thread to thread synchronization is somewhat faster than process
> > to process synchronization.  Honestly, the default thread synchronization
> > primitives typically blow the inter-process ones out of the water,
> > although there are some OS's and libraries that provide relatively
> > fast/cheap inter process syntonization.
> 
> 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.

No, there's a couple of tricks to get around that just using
locked cycles.

> Databases are different from many other applications in that they have a
> wide range of possible lock points and it is not easy to even guess
> where contention might be. For example, the discussed Postgres is pretty
> reader lock free due to the Multi Version Commit system. MySQL is
> different in that regard.

Regardless, cheaper locks are better, right?

> > Also, I'm pretty sure that synchronization between threads doesn't
> > require locked bus cycles, only atomic ops, again another saving.
> 
> Ahem. How do you expect two threads on different CPUs to synchronise
> correctly if no locked bus cycles are involved? It is important to
> distinguish atomic operation and atomic bus locked operations after all
> :-)

Ugh, you're right, userland threads in my mind. :(

Thanks.

-- 
- Alfred Perlstein