This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/10741] Merge tandem locks
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 20 Nov 2009 21:25:09 -0000
- Subject: [Bug translator/10741] Merge tandem locks
- References: <20091006202043.10741.jistone@redhat.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From jistone at redhat dot com 2009-11-20 21:25 -------
(In reply to comment #1)
> archiving irc yak on topic:
>
> fche anyway, I was thinking that another locking-related optimization could be
> done by escalating read-to-write locks within probe handlers
One concern is that we could lose atomicity this way. If two probes share a
read lock, and one wants to upgrade to write, it could timeout in waiting for
the other to release. Normally we can determine such skips on probe entry, so
the handler is all or nothing.
Or can we just allow the upgrade to block forever, since the shared probes are
bounded by MAXACTION?
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10741
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.