* [Bug translator/7033] New: Optimize locking reginon of global variables
@ 2008-11-14 23:27 mhiramat at redhat dot com
2008-11-14 23:44 ` [Bug translator/7033] " fche at redhat dot com
2008-11-27 17:12 ` fche at redhat dot com
0 siblings, 2 replies; 3+ messages in thread
From: mhiramat at redhat dot com @ 2008-11-14 23:27 UTC (permalink / raw)
To: systemtap
Currently, systemtap locks whole of a probe handler which uses global variables.
However, I think translator can shrink the locking region to the best size.
{
(lock(a) and lock(b))
...
a = xxx <- only here, we actually needs a's lock.
...
if (yyy)
b = zzz <- only here, we actually needs b's lock.
...
(unlock(a) and unlock(b))
}
--
Summary: Optimize locking reginon of global variables
Product: systemtap
Version: unspecified
Status: NEW
Severity: enhancement
Priority: P2
Component: translator
AssignedTo: systemtap at sources dot redhat dot com
ReportedBy: mhiramat at redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=7033
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug translator/7033] Optimize locking reginon of global variables
2008-11-14 23:27 [Bug translator/7033] New: Optimize locking reginon of global variables mhiramat at redhat dot com
@ 2008-11-14 23:44 ` fche at redhat dot com
2008-11-27 17:12 ` fche at redhat dot com
1 sibling, 0 replies; 3+ messages in thread
From: fche at redhat dot com @ 2008-11-14 23:44 UTC (permalink / raw)
To: systemtap
------- Additional Comments From fche at redhat dot com 2008-11-14 23:42 -------
A long time ago, this is how we used to do things.
Some reasons against it:
- generated code was much longer, as each use of those
globals had to be protected individually
- greater likelihood of deadlocks (which would be detected by
*trylock timeout loops, but that still takes time)
- by the time such a deadlock is detected, we can't roll back
the prior code run by the probe handler, so we end up with
inconsistent state
--
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
http://sourceware.org/bugzilla/show_bug.cgi?id=7033
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug translator/7033] Optimize locking reginon of global variables
2008-11-14 23:27 [Bug translator/7033] New: Optimize locking reginon of global variables mhiramat at redhat dot com
2008-11-14 23:44 ` [Bug translator/7033] " fche at redhat dot com
@ 2008-11-27 17:12 ` fche at redhat dot com
1 sibling, 0 replies; 3+ messages in thread
From: fche at redhat dot com @ 2008-11-27 17:12 UTC (permalink / raw)
To: systemtap
------- Additional Comments From fche at redhat dot com 2008-11-27 17:11 -------
For the reasons listed above, this idea is probably not worth pursuing.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution| |WORKSFORME
http://sourceware.org/bugzilla/show_bug.cgi?id=7033
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-11-27 17:12 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-11-14 23:27 [Bug translator/7033] New: Optimize locking reginon of global variables mhiramat at redhat dot com
2008-11-14 23:44 ` [Bug translator/7033] " fche at redhat dot com
2008-11-27 17:12 ` fche at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).