From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Concurrency Date: Mon, 29 Mar 2010 12:33:58 -0400 Message-ID: <224F559B-6F4F-4EFB-855C-B35C7DA24731@raeburn.org> References: <27349166.post@talk.nabble.com> <4B7564C7.1010309@swipnet.se> <27564728.post@talk.nabble.com> <4B756FB7.3050202@swipnet.se> <87k4ui4gik.fsf@lola.goethe.zz> <27566385.post@talk.nabble.com> <87wryi2sjd.fsf@lola.goethe.zz> <27585994.post@talk.nabble.com> <87k4ucdmwh.fsf@stupidchicken.com> <87d3zweq4e.fsf@master.homenet> <87y6hg1h4a.fsf@thor.thematica.it> <87tys3j9fa.fsf@lifelogs.com> <87eij6tqmu.fsf@lifelogs.com> <49707.130.55.132.67.1269807922.squirrel@webmail.lanl.gov> <87oci8rwtw.fsf@gnu.org> <87aatrigux.fsf@thor.thematica.it> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1269880653 2172 80.91.229.12 (29 Mar 2010 16:37:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 29 Mar 2010 16:37:33 +0000 (UTC) To: "emacs-devel@gnu.org discussions" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 29 18:37:29 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NwHxw-00014E-31 for ged-emacs-devel@m.gmane.org; Mon, 29 Mar 2010 18:37:28 +0200 Original-Received: from localhost ([127.0.0.1]:39771 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NwHxv-000070-7k for ged-emacs-devel@m.gmane.org; Mon, 29 Mar 2010 12:37:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NwHup-0007Ow-4I for emacs-devel@gnu.org; Mon, 29 Mar 2010 12:34:15 -0400 Original-Received: from [140.186.70.92] (port=54244 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NwHun-0007Ok-NO for emacs-devel@gnu.org; Mon, 29 Mar 2010 12:34:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NwHuh-00083z-UI for emacs-devel@gnu.org; Mon, 29 Mar 2010 12:34:13 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:48778 helo=raeburn.org) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NwHua-000836-7D for emacs-devel@gnu.org; Mon, 29 Mar 2010 12:34:07 -0400 Original-Received: from squish.raeburn.org (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id o2TGXwOX006263; Mon, 29 Mar 2010 12:33:59 -0400 (EDT) In-Reply-To: X-Mailer: Apple Mail (2.1077) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:122852 Archived-At: On Mar 29, 2010, at 11:37, Tom Tromey wrote: > I think it would be better to have all mutexes be recursive, because = it > is safer. I can see some desire for recursive mutexes, but I lean towards = Butenhof's view myself. If all mutexes are recursive, I'd like a way to = find out if I've already got a mutex locked, so I can manually detect = when I've screwed up my locking model, even if someone else wants to use = recursive mutexes in their code. BTW, one extension I'd suggest is an optional timeout for mutex-lock: = nil would mean block until the lock is acquired, a positive number would = mean wait up to that long (e.g., pthread_mutex_timedlock), and a = non-positive number would mean try to acquire the lock but don't wait. = I'm not sure offhand if failure to acquire the lock should be indicated = by throwing an error or a return value; I'm leaning a little towards = throwing an error. If this really catches on, read/write locks will probably be wanted too, = but they can be built on mutexes and condition variables initially, and = moved into C code later if they're really helpful and = performance-critical. For debugging, I think I'd want a way to check whether a particular = thread has locked a mutex. Not a predicate someone might be tempted to = use for non-debugging purposes, more like an assertion that throws an = error when false. > Also, I think mutex-unlock should throw some kind of error if the = mutex > is owned by a different thread. What do you think of that? Probably the best thing -- and likewise if the mutex isn't locked at = all. Ken=