associative array synchronization question

associative array synchronization question

[Nicholas Murphy]

Sorry for the very basic question: it says in the documentation that any probe using an associative array (which is necessarily global) will automatically hold a lock on that array for the duration of the probe...is that true regardless of whether the probe actually touches the array?  Or does it only lock on first access?

Thanks,
Nick

Re: associative array synchronization question

[Josh Stone]

On 07/20/2012 12:47 PM, Nicholas Murphy wrote:
> Sorry for the very basic question:

No need to apologize.

> it says in the documentation that any probe using an associative
> array (which is necessarily global) will automatically hold a lock on
> that array for the duration of the probe...is that true regardless of
> whether the probe actually touches the array?  Or does it only lock
> on first access?

When we take locks, we use the trylock functions (with a little spinning
and waiting), so we won't ever block forever.  That means sometimes we
can fail to take a lock.

We also chose to make probe handlers atomic, such that if a probe
handler runs at all, it must run in full.  We don't want to get into a
situation where a lock in the middle of a probe can't be obtained, thus
ruining that probe's execution flow.

Therefore, all locks needed for a handler are attempted before anything
is started in that handler, and held until the handler is done.  If any
of the locks can't be obtained, the probe is skipped entirely.

So for your case, where you may be conditionally writing an array, we
will be grabbing the write lock regardless of the condition (which we
don't know at that time).

If your data values can fit stats types (various numeric accumulation),
and you'll be writing values more often than you read, then a stats
array may be a better locking choice, because it only needs a fully
exclusive lock when reading instead.

Hope that helps, and feel free to ask followup questions.

Josh

Re: associative array synchronization question

[Nicholas Murphy]

Thank you!  That's clearer.

What does it mean that you "sometimes" fail to take a lock?  Do you just skip executing the probe if you determine that you can't get the lock?

Thanks,
Nick

On Jul 20, 2012, at 4:11 PM, Josh Stone wrote:

> On 07/20/2012 12:47 PM, Nicholas Murphy wrote:
>> Sorry for the very basic question:
> 
> No need to apologize.
> 
>> it says in the documentation that any probe using an associative
>> array (which is necessarily global) will automatically hold a lock on
>> that array for the duration of the probe...is that true regardless of
>> whether the probe actually touches the array?  Or does it only lock
>> on first access?
> 
> When we take locks, we use the trylock functions (with a little spinning
> and waiting), so we won't ever block forever.  That means sometimes we
> can fail to take a lock.
> 
> We also chose to make probe handlers atomic, such that if a probe
> handler runs at all, it must run in full.  We don't want to get into a
> situation where a lock in the middle of a probe can't be obtained, thus
> ruining that probe's execution flow.
> 
> Therefore, all locks needed for a handler are attempted before anything
> is started in that handler, and held until the handler is done.  If any
> of the locks can't be obtained, the probe is skipped entirely.
> 
> So for your case, where you may be conditionally writing an array, we
> will be grabbing the write lock regardless of the condition (which we
> don't know at that time).
> 
> If your data values can fit stats types (various numeric accumulation),
> and you'll be writing values more often than you read, then a stats
> array may be a better locking choice, because it only needs a fully
> exclusive lock when reading instead.
> 
> Hope that helps, and feel free to ask followup questions.
> 
> Josh

Re: associative array synchronization question

[Josh Stone]

On 07/20/2012 01:37 PM, Nicholas Murphy wrote:
> What does it mean that you "sometimes" fail to take a lock?  Do you
> just skip executing the probe if you determine that you can't get the
> lock?

The only failure is from contention.  We will spin-and-wait for a lock
to free up for a small time, but if it's too busy on other cpus, we'll
eventually give up.  That's "sometimes", but hopefully rare. :)

And yes, if we can't get all necessary locks, that probe handler will be
skipped altogether.

You can find a bit more about this on the wiki:
http://sourceware.org/systemtap/wiki/TipSkippedProbesOptimization

Josh