public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* [QUESTION] Is it safe to use lock in systemtap tapset?
@ 2018-10-17 15:18 Zexuan Luo
  2018-11-16 21:25 ` Frank Ch. Eigler
  0 siblings, 1 reply; 3+ messages in thread
From: Zexuan Luo @ 2018-10-17 15:18 UTC (permalink / raw)
  To: systemtap

Hi,
I am searching for some information about lock usage in the systemtap tapset.
Is it safe to use lock in systemtap tapset?
Maybe the answer is different for tapset used in different context
(timers, kernel.function, process.function, etc.)?
Which kind of lock should I use in the tapset?

Thanks for any reply.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [QUESTION] Is it safe to use lock in systemtap tapset?
  2018-10-17 15:18 [QUESTION] Is it safe to use lock in systemtap tapset? Zexuan Luo
@ 2018-11-16 21:25 ` Frank Ch. Eigler
  2018-11-17 14:00   ` Zexuan Luo
  0 siblings, 1 reply; 3+ messages in thread
From: Frank Ch. Eigler @ 2018-11-16 21:25 UTC (permalink / raw)
  To: Zexuan Luo; +Cc: systemtap


spacewanderlzx wrote:

> I am searching for some information about lock usage in the systemtap
> tapset.

The general advice is to avoid explicit locking in embedded-C functions,
since they may in principle run in any context, including atomic.  I am
not sure how explicitly we spell this out in [man stap] or
tapset/DEVGUIDE.


> Is it safe to use lock in systemtap tapset?
> Maybe the answer is different for tapset used in different context
> (timers, kernel.function, process.function, etc.)?
> Which kind of lock should I use in the tapset?

It depends on the shared resource you are concerned about, in what
probe/context you want to access them, whether you want to read or
write, and whether you can tolerate corrupt data or not.

Note: systemtap's own script-level global variables (and hidden runtime
state) are all already protected automatically.  There's no need to
initialize or worry about locking them.  (This is a unique feature in
systemtap, in contrast to almost every other tracing/probing system.)


- FChE

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [QUESTION] Is it safe to use lock in systemtap tapset?
  2018-11-16 21:25 ` Frank Ch. Eigler
@ 2018-11-17 14:00   ` Zexuan Luo
  0 siblings, 0 replies; 3+ messages in thread
From: Zexuan Luo @ 2018-11-17 14:00 UTC (permalink / raw)
  To: fche; +Cc: systemtap

Thank you for your reply!
Frank Ch. Eigler <fche@redhat.com> 于2018年11月17日周六 上午5:24写道:
>
>
> spacewanderlzx wrote:
>
> > I am searching for some information about lock usage in the systemtap
> > tapset.
>
> The general advice is to avoid explicit locking in embedded-C functions,
> since they may in principle run in any context, including atomic.  I am
> not sure how explicitly we spell this out in [man stap] or
> tapset/DEVGUIDE.
>
>
> > Is it safe to use lock in systemtap tapset?
> > Maybe the answer is different for tapset used in different context
> > (timers, kernel.function, process.function, etc.)?
> > Which kind of lock should I use in the tapset?
>
> It depends on the shared resource you are concerned about, in what
> probe/context you want to access them, whether you want to read or
> write, and whether you can tolerate corrupt data or not.
>
> Note: systemtap's own script-level global variables (and hidden runtime
> state) are all already protected automatically.  There's no need to
> initialize or worry about locking them.  (This is a unique feature in
> systemtap, in contrast to almost every other tracing/probing system.)
>
>
> - FChE

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-11-17 14:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-17 15:18 [QUESTION] Is it safe to use lock in systemtap tapset? Zexuan Luo
2018-11-16 21:25 ` Frank Ch. Eigler
2018-11-17 14:00   ` Zexuan Luo

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).