caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: padator@wanadoo.fr
Cc: skaller <skaller@users.sourceforge.net>,
	Asfand Yar Qazi <email@asfandyar.cjb.net>,
	caml-list@yquem.inria.fr
Subject: Re: [Caml-list] STM support in OCaml
Date: Wed, 08 Mar 2006 12:32:29 +0100	[thread overview]
Message-ID: <1141817549.10771.63.camel@localhost.localdomain> (raw)
In-Reply-To: <1474655.1141812700555.JavaMail.www@wwinf1632>

Am Mittwoch, den 08.03.2006, 11:11 +0100 schrieb yoann padioleau:
> > > You make several claims:
> > > 
> > > STM is not lock free.
> > > STM is not useful on a small number of processors
> > > 
> > > As for claim 1.  "Lock-free" doesn't mean what you think it does. 
> > 
> > I know what STM does, thank you: I intend to implement it
> > myself in my own programming language. Maybe you should
> > read more carefully.
> > 
> > I said "protected by a mutex under the hood." which means
> > sure, the programmer is not writing locks, but they're used
> > in the implementation and the associated costs are still paid.
> 
> I have read (very fastly) the atomcaml paper and I don't think they use "mutex under the hood".
> It seems that they just log stuff and rollback. I guess that when you want to implement 
> STM on multiprocessor you may need to mutex stuff (the internal data structures maintained by the STM runtime),
> but as ocaml runtime does not use multiprocessor, they dont need it.

In Atomcaml, the question whether there is a mutex or not simply does
not matter. They have their own scheduler (for bytecode), so there is no
need to have additional mutexes to protect the data structures Atomcaml
needs for itself, e.g. the log buffer. Being the scheduler is better
than any mutual exclusion...

If you ported Atomcaml to a kernel-level scheduler, you would surely
need mutexes (even in the uniprocessor case), simply because you need to
synchronize the kernel scheduler with user-level atomicity management.
So yes, for any real-world implementation, there are "mutexes under the
hood".

Anyway, I think this question is misleading. The point is not to
establish locking schemes that use the hardware better (i.e. that are
faster), but to help programmers writing correct code.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------


  parent reply	other threads:[~2006-03-08 11:32 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2006-03-08 12:04   ` skaller
2006-03-08 19:22     ` Dan Grossman
2006-03-08 22:10       ` skaller
  -- strict thread matches above, loose matches on Subject: below --
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-07 17:15 ` skaller
2006-03-07 19:05   ` Asfand Yar Qazi
2006-03-08  0:52     ` skaller
2006-03-08 10:38       ` 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
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-11 15:26             ` Florian Weimer

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=1141817549.10771.63.camel@localhost.localdomain \
    --to=info@gerd-stolpmann.de \
    --cc=caml-list@yquem.inria.fr \
    --cc=email@asfandyar.cjb.net \
    --cc=padator@wanadoo.fr \
    --cc=skaller@users.sourceforge.net \
    /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).