[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2006-03-09 (07:45) |
From: | Andrae Muys <andrae@i...> |
Subject: | Re: [Caml-list] STM support in OCaml |
On 09/03/2006, at 8:10 AM, Gerd Stolpmann wrote: > Am Donnerstag, den 09.03.2006, 09:06 +1100 schrieb skaller: >> On Wed, 2006-03-08 at 14:45 -0600, Brian Hurt wrote: >> >>> One comment I will make is that a mutex is expensive, but not *that* >>> expensive. I just wrote a quick program (available if anyone >>> cares) in >>> GNU C that measures the cost, in clocks, of locking and unlocking >>> a posix >>> mutex. On my desktop box (AMD Athlon XP 2200+ 1.8GHz), I'm >>> getting a cost >>> of like 44 clock cycles. Which makes it less expensive than an >>> L2 cache >>> miss. > >> I have no idea if Linux, for example, running SMP kernel, >> is smart enough to know if a mutex is shared between two >> processing units or not: AFAIK Linux doesn't support >> interprocess mutex. Windows does. Be interesting to >> compare. > > Of course POSIX supports interprocess mutexes: Mutexes are inherited > across fork(). As skeller suggested, I can confirm this does not work. Mutexes are not OS resources, they are initialised regions of memory (generally a word). As fork() does copy-on-write, this leads to the mutex being duplicated NOT shared; and yes given that fork() only duplicates the calling thread, that does mean you can end-up with mutexes locked in the child with no controlling thread available to unlock them. fork() safety is an important issue to be aware of when working with posix-threads. The best reference I am familiar with is Programming With Threads by Kleiman, Shah, and Smaalders, which includes a whole chapter on the this and related topics. > And Linux even implements threads as processes, so you > can even place mutexes in shared memory (but do not ask me how). I've done this in an embedded app I wrote a few years back. It's not hard, you create the shared-memory segment, cast some of it to be of type pthread_mutex_t and pass it to pthread_mutex_init() (I'm working from memory here, so the function/type names may be off). > Anyway, measuring the costs of a mutex is probably not simple. They > are > highly optimized for the frequently occurring cases. And today "SMP" > behaves often more like NUMA, especially for multi-core CPUs. Agreed, however in my experience, if optimistic locking isn't going to work for you then neither are mutex-based shared-memory approaches. Andrae Muys -- Andrae Muys andrae@netymon.com Principal Kowari Consultant Netymon Pty Ltd