Pros and Cons of a Singlethreaded AVM
I've been doing a lot of thinking lately about the Actionscript Virtual Machine (AVM). I know not too many developers concern themselves with diving deep into what makes Flash Player work, but I think it's important to understand the platform on which we stand and rely.
In a lot of ways, AVM is like JVM (Java Virtual Machine), and in a lot of ways, AVM is nothing like JVM. Perhaps the biggest difference is in threads. JVM is entirely multithreaded. As a Java developer, you could basically create an infinite loop creating an infinite number of threads of execution just as fast as your computer could handle it. You can also build applications that do everything synchronously, from opening server sockets and waiting for connections, opening/reading/writing to and from files, to just about anything imaginable. You can also do things asynchronously in Java, so you have the best of both worlds. AVM is explicitly single-threaded. Though AVM may run multiple threads in the background to give you the result you see, you as a developer have one and only thread to work with in development.
This is good and bad. The pros of a singlethreaded VM are as follows:
In a lot of ways, AVM is like JVM (Java Virtual Machine), and in a lot of ways, AVM is nothing like JVM. Perhaps the biggest difference is in threads. JVM is entirely multithreaded. As a Java developer, you could basically create an infinite loop creating an infinite number of threads of execution just as fast as your computer could handle it. You can also build applications that do everything synchronously, from opening server sockets and waiting for connections, opening/reading/writing to and from files, to just about anything imaginable. You can also do things asynchronously in Java, so you have the best of both worlds. AVM is explicitly single-threaded. Though AVM may run multiple threads in the background to give you the result you see, you as a developer have one and only thread to work with in development.
This is good and bad. The pros of a singlethreaded VM are as follows:
- Developers don't have to worry about threads, synchronization, and infinite loops. As soon as you introduce threads into a language, you as a developer have a lot more to worry about. For example, if you have two threads working on the same object at the same time, you could easily throw some variables off with one thread while the other is expecting a different result.
IE: Thread 1 is looking at an Object (which is typed as Object) and is casting it as a Number to perform some addition function on it. Thread 2, which is executing at the same time, grabs the Object and performs a subtraction function on it. Thread 1 applies the addition function it was planning on doing, and a crazy result is received. You as a developer are weeping in your chair wondering what the heck just happened. - Since there's only one thread, all operations taking a long (or indefinite) time are forced to be asynchronous. Meet the AVM Event flow system. Honestly, for a single-threaded VM, AVM really is powerful with its event system. Following the Observer design pattern, the event system makes it extremely easy for any developer to trigger asynchronous events at any time.
- There is little spreading of damage as far as performance is concerned. If the main thread is running slowly, the whole program is running slowly. In a single-threaded VM you can't just create a thread to handle some intensive process while the main thread does nothing.
- There is little spreading of damage as far as errors are concerned. The single-threaded AVM handles errors similarly yet different as compared to the JVM. Because of the one and only one thread that is running, developers must be careful to NEVER EVER LET AN ERROR BUBBLE TO THE TOP. If an error makes it all the way to the top to be displayed as a message in the debug player, it is an extremely bad thing for the application. I've had many bad things happen when errors are thrown. You could have an event listener for the ENTER_FRAME event break if an error happens at just the right time in just the right place. Even worse, if the error is in the ENTER_FRAME handler, performance will go down the drain. By multithreading a VM, you're typically going to have to use a lot more try..catch...finally blocks, which is good practice. Oh, and did I mention that if an error happens at runtime, it breaks whatever is next in its execution path? If you have code similar to this:
this.doSomething();
this.doSomethingElse();
...and an error is thrown in the doSomething() method, the doSomethingElse() method may never get called, throwing off your entire application. - You can't do things synchronously. Honestly, some times it's just easier to call File.open() then File.write() rather than construct a file object, add an event listener, try File.open(), then when it's finally loaded, do what you want with it.
- A single-threaded VM doesn't have multiple threads :)
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home