Re: associative array synchronization question

[Nicholas Murphy <nmurphy at eecs dot harvard dot edu>]

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