This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: iterations
- From: Martin Hunt <hunt at redhat dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Thu, 17 Mar 2005 10:21:42 -0800
- Subject: Re: iterations
- Organization: Red Hat Inc.
- References: <1111079053.5668.3.camel@tiger> <20050317180949.GL30517@redhat.com>
On Thu, 2005-03-17 at 13:09 -0500, Frank Ch. Eigler wrote:
> > What was the problem [brought up during a call] again? You wanted
> > to modify the map while iterating through it?
>
> There are several interesting cases.
> - nested iteration
> - map lookups at multiple indices during iteration
I think these work.
> - map modification during iteration
Is this really necessary? You can modify the values, but adding or
deleting elements in a map while iterating through it will be dangerous.
Fixing that will reduce efficiency.
> - concurrent reads / writes from different threads
I plan to add a rw spinlock to each map struct and modify the functions
to obtain the proper type of lock.
Iterations are a special problem because it really needs to be locked
between multiple calls. I had assumed we would modify the calling
sequence, like
_stp_lock_map (map);
... iterate here
_stp_unlock_map (map);
BTW, I should also mention that I realize that the state data stored in
the map struct must be valid between calls. That will be changed to be
per-cpu data to eliminate conflicts with multiple CPUs.
So _stp_map_key_xxx() only needs a reader lock as does _stp_map_get_xxx
(). _stp_map_set_xxx() and _stp_map_key_del() need a writer lock.
Martin