From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Tom Tromey <tromey@redhat.com>
Cc: Emacs development discussions <emacs-devel@gnu.org>
Subject: Re: advice needed for multi-threading patch
Date: Sun, 27 Sep 2009 19:05:07 -0400 [thread overview]
Message-ID: <jwvy6o09etq.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <m3iqf4qf3d.fsf@fleche.redhat.com> (Tom Tromey's message of "Sun, 27 Sep 2009 14:59:02 -0600")
Stefan> Indeed. The lock should probably be on the buffer-local binding itself
Stefan> (i.e. the combination of the buffer and the variable).
> I looked into this a bit; I think it can lead to deadlock too easily:
> Thread A acquires V1 and requests V2
> Thread B acquires V2 and requests V1
> Instead, I think we could remove the buffer lock. Because we currently
> use cooperative threading, most buffer operations are atomic with
> respect to thread switches. So, it seems that if we fix the bindings
> problem, we can probably just remove the buffer lock.
Removing locks sounds like a wonderful solution, but it's dangerous.
I think you understand the danger and refer to it as "the bindings
problem". But since I'm not sure I'll state what I think is the
problem:
thread T1 goes into buffer B and does a dynamic let-binding of
buffer-local variable X with value V1, then thread T2 does the same
thing with value V2.
What should that mean?
What should T1 see when it looks at X, V1 or V2?
What should T2 see when it looks at X, V1 or V2?
What did T2 see when it looked at X before let-binding it, V1 or V0?
What should T1 see when it looks at X after T2 ends its let-binding, V1 or V0?
What should T2 see when it looks at X after T1 ends its let-binding, V2 or V0?
You have to consider those cases and then look at existing code and see
what that code would expect. A good variable to start with is probably
default-directory (one of the most common buffer-local-and-let-bound
variables I know of), but others need to be considered as well (I'm not
sure they'll all agree on the behavior they expect).
Stefan
PS: Of course, similar questions arise with let-binding frame-local and
terminal-local variables, but I think these are much less common, so
it's probably OK to be less careful with them and just fix up the places
that break using explicit locks or things like that.
next prev parent reply other threads:[~2009-09-27 23:05 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-26 4:38 advice needed for multi-threading patch Tom Tromey
2009-08-26 7:06 ` Ken Raeburn
2009-08-26 14:52 ` Stefan Monnier
2009-08-26 18:50 ` Ken Raeburn
2009-08-27 3:12 ` Stefan Monnier
2009-08-27 6:28 ` Ken Raeburn
2009-08-27 17:02 ` Stefan Monnier
2009-08-26 16:08 ` Tom Tromey
2009-08-26 18:50 ` Ken Raeburn
2009-08-27 5:07 ` Miles Bader
2009-08-27 6:39 ` Ken Raeburn
2009-08-27 6:50 ` Miles Bader
2009-08-28 20:48 ` Juri Linkov
2009-08-28 22:15 ` Miles Bader
2009-08-28 23:27 ` Juri Linkov
2009-08-28 23:54 ` Miles Bader
2009-08-29 20:21 ` Richard Stallman
2009-08-26 15:02 ` Stefan Monnier
2009-08-26 15:31 ` Tom Tromey
2009-08-26 19:18 ` Stefan Monnier
2009-09-18 22:59 ` Tom Tromey
2009-09-19 0:09 ` Stephen J. Turnbull
2009-09-19 0:32 ` Chong Yidong
2009-09-21 21:19 ` Stefan Monnier
2009-09-21 21:50 ` Tom Tromey
2009-09-22 14:24 ` Stefan Monnier
2009-09-22 23:59 ` Ken Raeburn
2009-09-23 3:11 ` Stefan Monnier
2009-09-23 15:53 ` Chong Yidong
2009-09-23 3:16 ` Tom Tromey
2009-09-24 17:25 ` Stefan Monnier
2009-09-24 17:57 ` Tom Tromey
2009-09-27 20:59 ` Tom Tromey
2009-09-27 23:05 ` Stefan Monnier [this message]
2009-09-28 4:27 ` Tom Tromey
2009-09-29 0:27 ` Stefan Monnier
2009-09-29 2:26 ` Ken Raeburn
2009-09-29 3:20 ` Stefan Monnier
2009-09-29 3:57 ` Ken Raeburn
2009-09-29 3:33 ` Tom Tromey
2009-09-29 4:07 ` Ken Raeburn
2009-09-29 2:30 ` Tom Tromey
2009-09-23 18:43 ` Giuseppe Scrivano
2009-09-24 17:29 ` Stefan Monnier
2009-09-24 18:53 ` Giuseppe Scrivano
2009-09-24 20:04 ` Tom Tromey
2009-09-24 21:59 ` Stefan Monnier
2009-09-24 22:23 ` Giuseppe Scrivano
2009-09-24 22:47 ` Ken Raeburn
2009-09-28 14:52 ` Ted Zlatanov
2009-10-05 6:02 ` joakim
2009-09-28 7:44 ` Lynbech Christian
2009-08-29 0:28 ` Giuseppe Scrivano
2009-08-29 4:57 ` Tom Tromey
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=jwvy6o09etq.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=tromey@redhat.com \
/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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.