Re[2]: Problem: (missing) Synchronization and ActionMappings

[Matthias Kerkhoff <ma...@BESToffers.de>]

Hi Craig,

nice to get a response from you ;)

> Yah, I had just been thinking about those kinds of issues while contemplating
> switching to the Java2 collection classes.  I want to avoid synchronization if
> possible for the most common case (simply looking up a mapping), but I am not
> sure that's possible yet ...

>> Solutions ?

I've also thought a bit more on the subject. I see two general approaches
how this could be handled (both not completly satisfying)

Approach a: Reader/Writer lock on actions
The most general approach would be to add a Reader/Writer lock to the
action processing, allowing multiple "readers" (read: threads performing
an action) to execute concurrently and one "writer" (ie, the thread trying
to remove the mapping). However, this solution clearly has the highest
performance penalty, because it introduces locks to the yet (more or less)
unsynchronized standard execution path during request handling.

Approach b: Reference counting
This is a bit clumsy, but might be better regarding performance aspects.
The main problem arises due to the fact, that unregistering and execution
happen concurrently.
So, introducing a synchronized reference counter might help also. This
reference counter should be initially Action.addRef()'ed during registration
of an Action in an ActionMappings.
Each executing thread using Actions should properly call addRef()/release()
before/after execution of an Action.
If an ActionMapping wants to unregister an Action, it should remove it from
its hashmap and release it's own reference by calling action.release() -
thereby causing the reference count to reach zero sometimes later (when no
threads are perform'ing the action).
Action.release() should itself call setMappings(null) when it's reference
count has reached 0.
(The bad thing with this approach is that there is no way to enforce
 Action clients to properly call addref() and release() - usually not
 a good idea.)

-- 
Matthias                        (mailto:make@BESToffers.de)

Re[2]: Problem: (missing) Synchronization and ActionMappings

[Matthias Kerkhoff <ma...@BESToffers.de>]

Alec & all,

>>Approach a: Reader/Writer lock on actions

> It seems to be the better solution. How frequently mappings are dynamically
> added/removed in a typical app? My guess is that most apps are happy using static
> mappings without dynamically adding or removing.

It could be combined with flag solution Colin has suggested in his mail to
further reduce the cost.

>>Approach b: Reference counting

> Won't you need to protect by r/w locks reference counter increment/decrement in
> addRef/release in this approach? It could be much more costly than Approach a.

Yes, you're right.

-- 
Matthias                        (mailto:make@BESToffers.de)

Re: Problem: (missing) Synchronization and ActionMappings

[Alec Bau <Al...@msdw.com>]

>Approach a: Reader/Writer lock on actions

It seems to be the better solution. How frequently mappings are dynamically
added/removed in a typical app? My guess is that most apps are happy using static
mappings without dynamically adding or removing.

>Approach b: Reference counting

Won't you need to protect by r/w locks reference counter increment/decrement in
addRef/release in this approach? It could be much more costly than Approach a.

Alec

Matthias Kerkhoff wrote:

> Hi Craig,
>
> nice to get a response from you ;)
>
> > Yah, I had just been thinking about those kinds of issues while contemplating
> > switching to the Java2 collection classes.  I want to avoid synchronization if
> > possible for the most common case (simply looking up a mapping), but I am not
> > sure that's possible yet ...
>
> >> Solutions ?
>
> I've also thought a bit more on the subject. I see two general approaches
> how this could be handled (both not completly satisfying)
>
> Approach a: Reader/Writer lock on actions
> The most general approach would be to add a Reader/Writer lock to the
> action processing, allowing multiple "readers" (read: threads performing
> an action) to execute concurrently and one "writer" (ie, the thread trying
> to remove the mapping). However, this solution clearly has the highest
> performance penalty, because it introduces locks to the yet (more or less)
> unsynchronized standard execution path during request handling.
>
> Approach b: Reference counting
> This is a bit clumsy, but might be better regarding performance aspects.
> The main problem arises due to the fact, that unregistering and execution
> happen concurrently.
> So, introducing a synchronized reference counter might help also. This
> reference counter should be initially Action.addRef()'ed during registration
> of an Action in an ActionMappings.
> Each executing thread using Actions should properly call addRef()/release()
> before/after execution of an Action.
> If an ActionMapping wants to unregister an Action, it should remove it from
> its hashmap and release it's own reference by calling action.release() -
> thereby causing the reference count to reach zero sometimes later (when no
> threads are perform'ing the action).
> Action.release() should itself call setMappings(null) when it's reference
> count has reached 0.
> (The bad thing with this approach is that there is no way to enforce
>  Action clients to properly call addref() and release() - usually not
>  a good idea.)
>
> --
> Matthias                        (mailto:make@BESToffers.de)