avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Hawkes" <jhaw...@adsnm.com>
Subject Re: [RT] Notification pattern has interesting effects on IoC
Date Thu, 26 Feb 2004 17:42:33 GMT
This would work. :)

----- Original Message ----- 
From: "Leo Sutic" <leo.sutic@inspireinfrastructure.com>
To: "'Avalon Developers List'" <dev@avalon.apache.org>
Sent: Thursday, February 26, 2004 10:28 AM
Subject: RE: [RT] Notification pattern has interesting effects on IoC


> It is, but that's a broken implementation of copy-on-write (CoW).
> 
> You still need synchronization to comply with the Java memory model.
> There's no way to get around that.
> 
> The problem we have is this:
> 
>  + We have a list of listeners.
> 
>  + In order to send out an event to the listeners, we must
>    traverse the list and call handleEvent(e) on all of them.
> 
>  + But we also want to add and remove listeners.
> 
>  + We can't add/remove *and* traverse the list simultaneuosly
>    (ConcurrentModificationException).
> 
>  + So we could do this:
> 
>    synchronized void addListener (Listener l) { ... }
>    synchronized void removeListener (Listener l) { ... }
>    synchronized void fireEvent (Event e) { ... }
> 
>  + But then we can't have two fireEvent calls running
>    concurrently. That's bad.
> 
>  + So we do this: In fireEvent, synchronize on m_updateLock
>    long enough to obtain an iterator.
> 
>    Then, when we are about to mutate the list (add/remove)
>    lock the m_mutateLock (to prevent concurrent updates,
>    which is still a no-no). Then lock m_updateLock, and get
>    an iterator. release m_updateLock.
> 
>    Copy the list by using the iterator. (The list is
>    now unlocked and can be used in fireEvent. It is
>    guaranteed not to change, since we hold m_mutateLock.)
> 
>    Modify the copy.
> 
>    synchronize on m_updateLock
> 
>    Assign the copy to the list member field.
> 
>    release m_updateLock
> 
>    Release the m_mutateLock.
> 
> Then all writes are guaranteed to be flushed, and
> we minimize the time m_updateLock is locked.
> 
> 
> 
> /LS


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message