Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: as3 and concurrency  (Read 11331 times)
paulroth3d
Newbie
*
Posts: 1


View Profile Email
« on: December 23, 2009, 10:06:55 »

Hello,

  I was curious if anyone had any clarification on how Flash AS3 deals with threads? I noticed the following code in the View, and I wasn't sure if it was left for compatability with other more concurrent languages (Java,C,etc)

  Could anyone give an example where the notifiers might be modified during the notification loop?

PureMVC_AS3_2_0_4
[org/puremvc/as3/core/View.as]

{{{
96 :       /**
97 :        * Notify the <code>IObservers</code> for a particular <code>INotification</code>.
98 :        *
99 :        * <P>
100 :        * All previously attached <code>IObservers</code> for this <code>INotification</code>'s
101 :        * list are notified and are passed a reference to the <code>INotification</code> in
102 :        * the order in which they were registered.</P>
103 :        *
104 :        * @param notification the <code>INotification</code> to notify <code>IObservers</code> of.
105 :        */
106 :       public function notifyObservers( notification:INotification ) : void
107 :       {
108 :          if( observerMap[ notification.getName() ] != null ) {
109 :             
110 :             // Get a reference to the observers list for this notification name
111 :             var observers_ref:Array = observerMap[ notification.getName() ] as Array;
112 :
113 :             // Copy observers from reference array to working array,
114 :             // since the reference array may change during the notification loop
115 :                var observers:Array = new Array();
116 :                var observer:IObserver;
117 :             for (var i:Number = 0; i < observers_ref.length; i++) {
118 :                observer = observers_ref[ i ] as IObserver;
119 :                observers.push( observer );
120 :             }
121 :             
122 :             // Notify Observers from the working array            
123 :             for (i = 0; i < observers.length; i++) {
124 :                observer = observers[ i ] as IObserver;
125 :                observer.notifyObserver( notification );
126 :             }
127 :          }
128 :       }
}}}

  Also, if such a thing could occur, what thoughts did anyone have on using a more of an optimistic approach to the notification list - such as immutables (since it seems like it might not change nearly as often as notifications will be thrown).

thanks,
Paul
Logged
Justin
Full Member
***
Posts: 24


View Profile Email
« Reply #1 on: January 04, 2010, 03:20:39 »

Flash does not multi-thread so concurrency is never a concern for developers.  I can however, attampt to clarify how the notificationList is used as it relates to observers.

The observer array might change in the case of a notification triggering the creation of additional observers.  For example, if a notification response is to create a view component and that component has a Mediator with notification interests, Observers are created and added to that array prior to the loop completing but are not available until the next notification is sent. (again, no concurrency here)

The notification list itself is used just a single time as a map for creating observers when a Mediator is created.  If the list is altered at runtime after the observers have been created, nothing will result.  That being said, an immutable becomes superlative.

@cliff - this was what I gathered as I was doing the MooTools JS port.  Is this accurate?

J-
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #2 on: January 05, 2010, 01:44:52 »

Yep. The thing that forced this particular implementation was that when one mediator in a list of observers responds to the note by deleting itself, the subsequent mediator in the list would be skipped because the list was shortened before the next iteration of the notification loop.

So if observer 2 in a list of 5 removes itself, then 3, 4 and 5 become 2, 3 and 4 in the list. The iterator was at 2, then it moves to three and the mediator that was 3 but became 2 is thus skipped.

-=Cliff>
Logged
Pages: [1]
Print