From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Julian Graham" Newsgroups: gmane.lisp.guile.devel Subject: Re: srfi-18 requirements Date: Wed, 26 Mar 2008 11:55:54 -0400 Message-ID: <2bc5f8210803260855m2f1a8295v5b9becfa615c7a8d@mail.gmail.com> References: <2bc5f8210710101854m1254160ei451026182b87e767@mail.gmail.com> <87r6f5zv6t.fsf@ossau.uklinux.net> <2bc5f8210802212014o45a9c79dpd688f11726a1e159@mail.gmail.com> <87ir0e1yka.fsf@ossau.uklinux.net> <2bc5f8210802241017o46468365j33c329a069d96d33@mail.gmail.com> <873ariaq82.fsf@ossau.uklinux.net> <2bc5f8210803011156i3bfb976bsda2a7902654ba3a6@mail.gmail.com> <87bq5pb2ea.fsf@ossau.uklinux.net> <2bc5f8210803102102p31da06b5jfa7807bb727907a7@mail.gmail.com> <87myonlqys.fsf@ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1206546983 6742 80.91.229.12 (26 Mar 2008 15:56:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Mar 2008 15:56:23 +0000 (UTC) Cc: =?ISO-8859-1?Q?Ludovic_Court=E8s?= , guile-devel@gnu.org To: "Neil Jerram" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Mar 26 16:56:44 2008 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JeXzW-0006Ke-Qr for guile-devel@m.gmane.org; Wed, 26 Mar 2008 16:56:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JeXyt-0001E6-VQ for guile-devel@m.gmane.org; Wed, 26 Mar 2008 11:56:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JeXyr-0001CO-Ea for guile-devel@gnu.org; Wed, 26 Mar 2008 11:56:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JeXyq-0001B6-Mm for guile-devel@gnu.org; Wed, 26 Mar 2008 11:56:00 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JeXyq-0001Av-KE for guile-devel@gnu.org; Wed, 26 Mar 2008 11:56:00 -0400 Original-Received: from hu-out-0506.google.com ([72.14.214.239]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JeXyo-0006k7-KS for guile-devel@gnu.org; Wed, 26 Mar 2008 11:55:59 -0400 Original-Received: by hu-out-0506.google.com with SMTP id 23so2218669huc.1 for ; Wed, 26 Mar 2008 08:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=y9LtAS7F5v2FNg1UAGknn/XdpBe2v5/LMLNgrzCB0QQ=; b=gNFSIqRVLorjk0kwl6owPiTcktWw5ov9AlIfetyRuTYUk8uu1MxV3vc+Sbrz+yXkbpZpUbDhOpTCKb8oBucv1CIEWiDUSe2EMpQ0mU2dJ4+o7zGIiO9HzrkAcms24VbladGZupOmXnJamSjAVK2PloHmTU8uyXf9rBEIEbyhcNc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OSCaJLO8RT5iZObEawlb7BmsaIzEpMFXsU6z7/CKQXHAj5iNc5p4g82PEaVzV+wdrz9ZW2kqfCGNIdM6FvhgXKxASG2XeDwLWoDsDgX0OBqqC2jHq7enq9HC3KDKDEChlZr/YbXUyJ9uFZD/Dgkqg1zQLVCz29m/ngqXcbTTkww= Original-Received: by 10.82.112.3 with SMTP id k3mr254395buc.32.1206546954364; Wed, 26 Mar 2008 08:55:54 -0700 (PDT) Original-Received: by 10.82.166.7 with HTTP; Wed, 26 Mar 2008 08:55:54 -0700 (PDT) In-Reply-To: <87myonlqys.fsf@ossau.uklinux.net> Content-Disposition: inline X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:7097 Archived-At: > I also see no problem - in API terms - with un-ifdefing > scm_mutex_owner (and scm_mutex_level, while we're there). Could you > just review, though, whether you're happy with their implementation? > In particular, should these functions lock and unlock m->lock? Given that SCM is supposed to be more or less opaque, I think it's probably safer to at least lock within scm_mutex_owner. Otherwise, I'm happy with those C implementations. ...Except that I've run into a few more snags related to ownership when it comes to mixing of core calls and SRFI-18 calls -- specifically, notifying the SRFI-18 implementation of changes to ownership that occur as a result of locking / unlocking a mutex from the core code. For example, what should be the result of `mutex-state' after the following series of expressions? (use-modules (srfi srfi-18)) (define m (make-mutex)) (mutex-lock! m (current-time) #f) (unlock-mutex m) (lock-mutex m) ...according to the pure Scheme ownership implementation you suggested back in January, locking a mutex via SRFI-18 `mutex-lock!' with an explicit non-current-thread owner would set an object property on the mutex, but if core code that is unaware of the SRFI-18 implementation details unlocks and relocks the mutex, the object property gets out of sync in a way that I don't think is possible to detect. (Or is this not a valid use case? My understanding based on our previous conversations is that we want core and SRFI-18 code to be able to co-exist as much as possible...) There's a related problem with SRFI-18's requirement that threads waiting on mutexes be notified when the owner thread exits -- the core implementation now notifies waiters when the owner exits, but as far as the core is concerned, the owner will always be the thread that called `lock-mutex'. A possible solution that comes to mind is making the core aware of any object properties that SRFI-18 defines, but that's not optimal from a design point of view. > But that's spec vs. implementation. I'd tend to give the spec writers > the benefit of the doubt here, i.e. to assume that they had reasonable > implementations in mind where it would be a performance hit. > > (And of course, the pthreads point/argument doesn't transfer in detail > across to Guile's API, because our mutexes offer a lot more features > than the base pthreads mutexes.) Certainly -- I was just looking for reasons that `mutex-owner' shouldn't be enabled. (My expectation was that the pthreads spec would reject features like that on the basis that "good" multi-threaded code shouldn't need to query things like mutex ownership, but I didn't see any objections on that front...) Regards, Julian