caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: Alex Baretta <alex@baretta.com>
Cc: Shawn Wagner <shawnw@speakeasy.org>,
	caml-list@inria.fr, ranjan.bagchi@frotz.com
Subject: Re: [Caml-list] Best way to synchronize OS processes?
Date: 12 May 2004 14:53:40 +0200	[thread overview]
Message-ID: <1084366421.20597.12.camel@ares> (raw)
In-Reply-To: <40A20A0F.2070809@baretta.com>

Am Mit, 2004-05-12 um 13.27 schrieb Alex Baretta:
> Shawn Wagner wrote:
> > On Tue, May 11, 2004 at 11:05:23AM -0700, Ranjan Bagchi wrote:
> > 
> >>Hi --
> >>
> >>I'm writing some code which will end up executing concurrently on 
> >>several OS processes.  I'd like to serialize access to some specific OS 
> >>resources (for instance, writing to a single file).  The Unix module 
> >>doesn't appear to offer anything like a critical section or an OS 
> >>mutex.  Is there a preferred way to do this?
> > 
> > 
> > File locking with Unix.lockf?
> 
> I disagree. I faced the same problem and found that it cannot be easily 
> solved with lockf. Unix.lockf locks specific regions in a file, whereas 
> Ranjan seems to need the equivalent of a mutex, which should be 
> implemented as a lock over the entire file. This is done by the flock 
> primitive in Posix systems. Unluckily, flock has not been included in 
> the Unix module.

And this is good. flock is not as portable as lockf. flock usually does
not work over NFS, whereas lockf works. Normally, you need flock only to
synchronize with third-party BSD programs such as sendmail.

lockf does not lock regions of a file. It just locks abstract
byteranges, whether you interpret them as file regions is up to you.
That means, you can lock byteranges that do not exist in the file. If
you like, you can view an empty lockf-locked file as 2^32 potential
mutexes (or whatever the maximum file size is).

Gerd 
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  parent reply	other threads:[~2004-05-12 12:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-11 18:05 Ranjan Bagchi
2004-05-11 18:09 ` Shawn Wagner
2004-05-11 18:24   ` Ranjan Bagchi
2004-05-12  7:01     ` Jean-Christophe Filliatre
2004-05-12 16:35     ` Ranjan Bagchi
2004-05-12 11:27   ` Alex Baretta
2004-05-12 11:46     ` Ville-Pertti Keinonen
2004-05-12 13:16       ` Olivier Andrieu
2004-05-12 12:53     ` Gerd Stolpmann [this message]
2004-05-11 18:10 ` Richard Jones
2004-05-12 16:52 ` Shawn Wagner

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=1084366421.20597.12.camel@ares \
    --to=info@gerd-stolpmann.de \
    --cc=alex@baretta.com \
    --cc=caml-list@inria.fr \
    --cc=ranjan.bagchi@frotz.com \
    --cc=shawnw@speakeasy.org \
    /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).