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.)

Answer 2

After burying myself in Flex and Actionscript for several months, I've moved back to .NET; and I'm a bit re-overwhelmed by all the various modes I have to choose from - or, alternately, I must choose from and orchestrate.

In contrast, Flex/AIR has pretty much one simple but complete set of SDK calls for data and file manipulation, each with synchronous and asynchronous variants. It's much easier to understand and use consistently.

Roger's right from my experience. Flex/AS# Just Works. .NET, decreasingly so (from option overload, IMHO). One consequence is that .NET accommodates edge scenarios better; but if Flex/AS3 can handle your requirements, it will probably do it easily. Think 80/20 Rule (or probably better.)

I think your question has been addressed by Roger, but let me say it the way I think I heard it.

Your method is single-threaded (along with other UI activity) on a common UI thread. But resources (files, dbms ports, etc.) typically go through a simple sequence that you typically set up like this:

1. Instantiate an object of the desired resource class,
2. Register an event handler for the return event on the object (say "fileonOpen"),
3. Call the async execution method for the object (say "file.open").
4. The UI event loop continues,
5. The resource eventually completes its method execution, and fires the event handler you registered, which now runs on the UI thread, Maybe the answer to your question is that the event handler is given an argument which is the object it pertains to, so you you can delete it from your collection. Presumably your object is well enough self-identified to prevent confusion in dealing with the collection to which it belongs. If it's a database result row, it would presumably know its own PK value. File objects have properties like nativePath, isDirectory, parent (another File object), etc.

Answer 3

The answer to your question, as you've described it, is no. While knowing about event registration, event dispatching, priorities, asynchronousness, etc., is all valuable, the fact remains you're doing the work of modifying the ArrayCollection within the scope of a single function on the main thread, which will be followed by the second invocation of that function, also on the main thread -- so you've got nothing to worry about in terms of concurrency: while it's true you might not know which object gets there first (for lots of reasons), you can be certain the second one will get the product of the work performed by the first one.

So no, you're good to go. Rock on!