From: Andrae Muys <andrae@internode.on.net>
To: Gerd Stolpmann <info@gerd-stolpmann.de>
Cc: skaller <skaller@users.sourceforge.net>,
Brian Hurt <bhurt@spnz.org>,
caml-list@yquem.inria.fr, William Lovas <wlovas@stwing.upenn.edu>
Subject: Re: [Caml-list] STM support in OCaml
Date: Thu, 9 Mar 2006 17:45:10 +1000 [thread overview]
Message-ID: <03CA5DC7-2934-42E0-A3A1-2D77F241F5D0@internode.on.net> (raw)
In-Reply-To: <1141855850.10771.100.camel@localhost.localdomain>
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
next prev parent reply other threads:[~2006-03-09 7:45 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-07 16:18 Asfand Yar Qazi
2006-03-07 16:50 ` [Caml-list] " Sebastian Egner
2006-03-07 17:44 ` Michael Hicks
2006-03-08 0:37 ` Asfand Yar Qazi
2006-03-08 5:05 ` Erick Tryzelaar
2006-03-11 19:43 ` Deadlock free locking scheme (was: Re: [Caml-list] STM support in OCaml) David MENTRE
2006-03-07 17:15 ` [Caml-list] STM support in OCaml skaller
2006-03-07 19:05 ` Asfand Yar Qazi
2006-03-08 0:52 ` skaller
2006-03-08 7:08 ` Bardur Arantsson
2006-03-08 10:38 ` [Caml-list] " Asfand Yar Qazi
2006-03-08 19:36 ` William Lovas
2006-03-08 20:45 ` Brian Hurt
2006-03-08 21:14 ` Paul Snively
2006-03-08 22:06 ` skaller
2006-03-08 22:10 ` Gerd Stolpmann
2006-03-08 23:48 ` skaller
2006-03-09 7:45 ` Andrae Muys [this message]
2006-03-09 9:18 ` David Brown
2006-03-08 22:11 ` Brian Hurt
2006-03-08 23:05 ` Lodewijk Vöge
2006-03-09 3:13 ` Brian Hurt
2006-03-08 23:45 ` Robert Roessler
2006-03-09 0:23 ` skaller
2006-03-09 3:19 ` Brian Hurt
2006-03-09 4:32 ` skaller
2006-03-09 10:38 ` John Chu
2006-03-09 16:53 ` Stefan Monnier
2006-03-11 15:26 ` [Caml-list] " Florian Weimer
2006-03-08 10:11 yoann padioleau
2006-03-08 10:41 ` Asfand Yar Qazi
2006-03-08 12:23 ` skaller
2006-03-08 23:02 ` Asfand Yar Qazi
2006-03-09 0:36 ` skaller
2006-03-08 11:32 ` Gerd Stolpmann
2006-03-08 12:04 ` skaller
2006-03-08 19:22 ` Dan Grossman
2006-03-08 22:10 ` skaller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=03CA5DC7-2934-42E0-A3A1-2D77F241F5D0@internode.on.net \
--to=andrae@internode.on.net \
--cc=bhurt@spnz.org \
--cc=caml-list@yquem.inria.fr \
--cc=info@gerd-stolpmann.de \
--cc=skaller@users.sourceforge.net \
--cc=wlovas@stwing.upenn.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).