From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id F31C5BC69 for ; Tue, 13 Nov 2007 11:14:33 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAC4IOUfAbSoIh2dsb2JhbACPCAEBAQgKKQ X-IronPort-AV: E=Sophos;i="4.21,410,1188770400"; d="scan'208";a="19222589" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail4-smtp-sop.national.inria.fr with ESMTP; 13 Nov 2007 11:14:33 +0100 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from einhorn.in-berlin.de (localhost [127.0.0.1]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id lADAEWhP012956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 13 Nov 2007 11:14:32 +0100 Received: (from www-data@localhost) by einhorn.in-berlin.de (8.13.6/8.13.6/Submit) id lADAEW4Y012953 for caml-list@yquem.inria.fr; Tue, 13 Nov 2007 11:14:32 +0100 X-Authentication-Warning: einhorn.in-berlin.de: www-data set sender to oliver@first.in-berlin.de using -f Received: from dslb-088-074-016-055.pools.arcor-ip.net (dslb-088-074-016-055.pools.arcor-ip.net [88.74.16.55]) by webmail.in-berlin.de (IMP) with HTTP for ; Tue, 13 Nov 2007 11:14:32 +0100 Message-ID: <1194948872.473979088166f@webmail.in-berlin.de> Date: Tue, 13 Nov 2007 11:14:32 +0100 From: Oliver Bandel To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Why 'Graphics.wait_next_event' doesn't reply anymore ? References: <20071110230145.3aebafe4@localhost.localdomain> <20071111150720.4f8d1c44@localhost.localdomain> <1194799714.473732620f33e@webmail.in-berlin.de> <20071111204019.4697d387@localhost.localdomain> <1194828182.4737a196e3582@webmail.in-berlin.de> <20071112205411.0d2d6dfc@localhost.localdomain> <1194902314.4738c32a070fd@webmail.in-berlin.de> <20071113084547.2214223f@localhost.localdomain> In-Reply-To: <20071113084547.2214223f@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Spam: no; 0.00; bandel:01 in-berlin:01 mutexes:01 module's:01 ocaml:01 scheduler:01 mutexes:01 ocaml-team:01 threads:01 threads:01 oliver:01 oliver:01 caml-list:01 functions:01 functions:01 Hi, Zitat von Fabrice Marchant : > > Both threads use the Graphics-module (via View-module). > > Possibly the problem is, that the access > > is not protected: use Mutexes, when calling the View., > > so that each Thread only has access to the View-functions > > (and the Graphics module's functions), when the other thread > > is ready with it's work. Otherwise possibly things become confused. > > > > So, wrap each of the View. calls with > > calls to Mutex.lock and Mutex.unlock. > > > > Possibly this is your main problem! > > Great ! Oliver, it was this. All perfectly rocks at full speed now. Heheh, fine. So, it was not OCaml nor the Graphics module that is buggy ;-) > I'm very happy my Game of Life finally works. Are the new sources online? How to play it? Now that it works, I may play around with it for a while.... :) > However, I've not understood why this Mutex was needed : what could be > the data shared with 'wait_next_event' ? > Some internal of Graphics module ? Yes, Graphics modules internals. Both threads might share a lot of data. They are drawing at the same screen, so if their work might be interrupted by the scheduler before the data was written completely, something might go wrong. If you can't be sure that the data is isolated, use Mutexes. And in the case of the Graphics-module you don't get back a value that holds something, e.g. when using the initialization functions. So seemingly they all write on the same data. (And to have a copy of the whole screen always, would be wasting memory, so I think it's ok this way.) One could write a wrapper-lib for it, so that the Mutex-stuff is already inside then. But that is something that should be up to the users of the Graphics-module (and not the OCaml-team), because needs and design might be differing a lot. If people for example would not want to have Threads inside, with such a wrapper-lib they would be inside nevertheless. And that's, how bloat-projects start to evolve. ;-) Ciao, Oliver