Do I need to worry about concurrency issues in my Flex/AIR code?

Question

I have a situation where I'm starting a number of objects that, when they are ready to handle some input data, call a handler.

That handler gets a dataset from an ArrayCollection of pending requests, assigns it to the object, and removes the dataset from the ArrayCollection.

(I can't pop from the ArrayCollection because I need to search through it to find an appropriate dataset - it isn't always the one on top.)

Is it possible that two objects could call my handler in such a way that (1) the first is assigned a dataset, (2) the second is assigned the same dataset before the instance of the handler servicing the first has deleted it and I guess (3) the second instance of the handler errors on trying to delete the dataset from the ArrayCollection.

I'm not familiar enough with the Flash Player runtime to know if this failure scenario is even possible, or if I should take the extra time to put some sort of locking in place to prevent it.

---

Edit: The answers so far give glowing reviews for Flex, but I'm not sure they answer the question. To be clear, I'm not trying to decide whether or not to use Flex.

If I have a method that:

1. Gets a piece of data from somewhere in an ArrayCollection
2. Does something with that data
3. Removes that data from the ArrayCollection

Is it possible that another invocation of that same method could do #1 after the first invocation does #1 but before it does #3?

le dorfier, you said that Flex/AS "just works" - can you clarify that it will "just work" in this case?

Answer 1

You don't need to do locking but you might want to track order of modifications to your state. Different async calls that are in play could return and modify your model state in an order that is different from when they async calls were issued.

Flex and AIR applications have a single threaded programming model. However, their architecture relies on asynchronous I/O for interactions with the server-tier.

Now in a Java Swing app or .NET Winforms app, one might do i/o interactions on a back-ground thread and marshal arguments/results to and from the main GUI thread. (Those graphical UI libraries do not permit other threads to change state of graphical toolkit objects/widgets, and hence data interactions must be marshaled to and from other background processing threads.)

In contrast, the i/o class library of Flex and AIR is written where these classes implement i/o operations asynchronously. For instance, to do an HTTP GET, the HttpSerivce send() method can be invoked, which is not a blocking call. Instead an ActionScript3 closure can be supplied to handle the result whenever the call eventually completes and returns.

In the meantime, the Flex/AIR app can permit the GUI to continue to be fully interactive to the user. It can even display a progress indicator and/or a Cancel button.

So it turns out that even though the Flex/AIR single-threaded GUI model is simpler and easier to program than multi-threaded Java Swing or .NET Winform applications, it is capable of the same kind of sophisticated UI behavior as those style of rich client applications.

A simple event-driven single threaded GUI, async i/o (via service calls and/or messaging), coupled with ActionScript3 closures for processing results or faults, is the Flex/AIR secret recipe for world domination. (Of course I should mention the good support for properties, events, and nice declarative - or imperative - data binding too as part of this world conquering strategy.)