From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <romain.beauxis@gmail.com>
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	by yquem.inria.fr (Postfix) with ESMTP id 5BAB5BC37
	for <caml-list@yquem.inria.fr>; Wed, 27 Jan 2010 15:48:28 +0100 (CET)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArcEAPzgX0tYvxGE/2dsb2JhbACBNJAMtxSGdYg0gjCCCQSDJA
X-IronPort-AV: E=Sophos;i="4.49,354,1262559600"; 
   d="scan'208";a="42569368"
Received: from www.rastageeks.org (HELO mail.rastageeks.org) ([88.191.17.132])
  by mail3-smtp-sop.national.inria.fr with ESMTP; 27 Jan 2010 15:48:28 +0100
Received: from leonard.localnet (adsl-150-16-42.aby.bellsouth.net [72.150.16.42])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.rastageeks.org (Postfix) with ESMTPSA id 337E2BC307
	for <caml-list@yquem.inria.fr>; Wed, 27 Jan 2010 15:48:27 +0100 (CET)
From: Romain Beauxis <romain.beauxis@gmail.com>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Problem with try_lock on win32.
Date: Wed, 27 Jan 2010 08:54:08 -0600
User-Agent: KMail/1.12.4 (Linux/2.6.30-2-amd64; KDE/4.3.4; x86_64; ; )
References: <201001262045.49994.romain.beauxis@gmail.com> <004001ca9f29$fffac320$fff04960$@romulus.metastack.com>
In-Reply-To: <004001ca9f29$fffac320$fff04960$@romulus.metastack.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201001270854.09085.romain.beauxis@gmail.com>
X-Spam: no; 0.00; printf:01 printf:01 afaik:01 otherlibs:01 systhreads:01 stubs:01 ocaml:01 mutexes:01 windows-only:01 bug:01 semantics:01 threads:01 abstract:01 assert:01 assert:01 

	Hi !

Le mercredi 27 janvier 2010 02:23:25, David Allsopp a =E9crit :
> Romain Beauxis:
> > I have a problem with the following code under win32:
> >=20
> > let m =3D Mutex.create ()
> >=20
> > let () =3D
> >   Mutex.lock m;
> >   if Mutex.try_lock m then
> >     Printf.printf "locked !\n"
> >   else
> >     Printf.printf "could not lock!\n"
>=20
> This code is behaving correctly for a Windows mutex (AFAIK - I can't find
> the relevant bit in the Synchronisation on MSDN atm) - once a thread has
> locked a Windows mutex, WaitForSingleObject will return WAIT_OBJECT_0 (i.=
e.
> success) because for that thread the mutex is signalled (it's only other
> threads which will see the object as non-signalled). I guess it's a
> philosophical discussion for whether it's useful for a thread to be able =
to
> block itself permanently by trying to lock a mutex which it has already
> locked (the POSIX way).
>=20
> One possible fix to make it behave like POSIX would be to patch
> otherlibs/systhreads/win32.c so that caml_mutex_lock records the thread ID
> of the thread when it locks the mutex. Some trick would be required to
>  block the thread (permanently) if it calls Mutex.lock twice (to match the
>  POSIX behaviour). caml_mutex_try_lock can check the thread ID before usi=
ng
>  WaitForSingleObject and return false if it shows that it's locked and
>  caml_mutex_unlock would clear the thread ID to null on a successful
>  release. Two potential problems (which I'm guessing other Windows users =
on
>  the list may comment on, if relevant):
>=20
> a) The representation of a mutex internally (the abstract value) changes
> which means that any Windows C stubs which interoperate with OCaml mutexes
> would break.
> b) The behaviour of Mutex.lock and Mutex.try_lock under Windows would be
> altered to be non-Windows-like behaviour which may affect existing
> Windows-only programs which rely on it.
>=20
> But you could raise it as a bug in Mantis just for cross-platform
> consistency of the Mutex module (another option would be to have a separa=
te
> module PosixMutex with the guaranteed consistent semantics and leave the
> Mutex module as behaving in an OS-specific way)

Thank you for your detailed and enlighting answer !

I have no problem with this behaviour for myself and I don't think we need =
to=20
change it: the case where a thread blocks itself should be a minotiry, if n=
ot=20
never exist.

=46or the record, we reached this issue with code like:
  assert( not (Mutex.try_lock m))
In this case, the assert would fail, although the program should still beha=
ve=20
correctly under win32...

The only thing that would be nice is to have this written somewhere in the=
=20
Mutex module documentation..


Romain