Lock free operation:

By its very design, all event handlers in AMPS run serially and asynchronously within the context of a single thread. This consequently results in a ‘Shared Nothing Architecture' . When nothing is shared, there is no need to lock anything. AMPS code requires no locks, no mutexes, and no semaphores ever. Even the AMPS code itself is built without any synchronization primitives. Tens of highly concurrent applications developed over AMPS so far can clearly vouch that it is always possible to write applications without locking primitives.
This saves all time in context switching of threads, busy waiting on spinlocks or similar constructs and allows the applications to grow linearly with little to no “parallel slowdown" problems.
Additionally AMPS guarantees not just an “Obstruction free"but a “Lock Free" execution of its event handlers. A higher priority event handler can even guarantee a “wait free" execution which is the strongest guarantee of execution for any concurrent system. AMPS further gives some assurances about “starvation freedom" for its event handlers.
It also partially solves the ‘priority inversion' problem which comes when a thread of lower priority is holding a resource which a thread of higher priority wants. This inverts the priority because the higher priority thread needs to wait for lower priority thread to finish. With no locks, AMPS still needs to wait for the lower priority event handler to finish but that event handler is guaranteed to finish in deterministic time and giving at least a guaranteed response time to higher priority thread.

Predictability in performance (Determinism)
As mentioned before, thread-based programs are inherently unpredictable due to involuntary context switching between threads and the blocking nature of concurrency primitives.
AMPS code by design is divided into Event Handlers that are atomic units of execution and never block on anything before termination. They all execute serially within the context of one main thread.
If there is any interface that requires synchronous communications, that code is specifically separated into modules called I/O agents which are non-deterministic by their very nature. This non-determinism is judiciously introduced if required. This is in contrast to threaded systems where non-determinism is removed where not required.
The performance and throughput of the event scheduler can therefore be easily predicted. The application’s performance grows linearly with the number of event handlers and also depends upon the order in which events are served.

No Race Conditions:
As mentioned before, race conditions are a natural consequence of parallel executing code. It is always possible for an event that started after the other to end up before. This can have disastrous bugs which are very subtle to handle.
Since AMPS serializes per force the execution of all code, race conditions are not a possibility. Even if they can occur (may be in the network), they can be easily modelled in the FSM and a proper event handler written for them. They will still never cause any waiting of execution.

Separation of concerns

As mentioned before there are concerns which pertain to the problem itself and others which pertain to the runtime environment provided to the application to run. Conventional programming methods deeply mix the two types of concerns.
AMPS makes a conscious effort to separate the two types of concerns and provide explicit mechanisms for this purpose.
These mechanisms provide a paradigm shift for the programmer and enable her to concentrate on the application logic. The programmer worries about how to divide the application into modules, and then the modules into event handlers, and then design the central FSM of the application. Once done, she writes event handlers which always execute atomically.

Support for SMP: Separating parallelism from how it is implemented

Support for SMP: Separating parallelism from how it is implemented

We believe that the programmer should only deal with identifying the parallelism in the application. Once she has identified the parallelizable parts of the application, she only needs to tell the middleware that this atomic part of code needs to be serialized with respect to other instances of the same code. Otherwise, by default the middleware may schedule each atomic part of the application on any available processors.
 
AMPS takes care of distributing the events across processors for maximum speed under simple directions from the programmer. AMPS keeps track of all available processors and the load on them. It could even distribute events across machine boundaries to processors available on other machines. This makes AMPS fully adaptive and ready for Cloud computing challenges. 
Support for AMP: Specialized hardware and software servers
Today’s multi-core processors have exposed a possibility of running different codes on different cores. Some of these cores may be specialized for DSP or floating point etc.
AMPS is based on a highly scalable architecture that makes easy distribution of application possible, this fact can be utilized to run different components or modules of an application on specialized hardware e.g. one or more machines could be dedicated to Digital Signal Processors (DSPs), others could be reserved for high performance text parsing and so on. This way one could create specialized clusters of dedicated hardware and software components serving in collaboration under the control of the master FSM of the application to achieve high performance and scalability. This is in fact one of the key features and goals of envisioned Cloud computing paradigm.

Tasks distribution, scalability and cloud readiness
AMPS decouples different parts of the application from each other through the use of events, and the data for each event is transferred to its handler by message passing. An application built upon AMPS can scale across machine boundaries quite transparently from the programmer. An application designer only has to install different parts of the application on different machines of his choice. A central AMPS application could dispatch events to a part of the application running on a machine that may be on a different geographical location.
 
This takes the notion of ‘write once, run anywhere’ to the next higher level where ‘anywhere’ isn’t restricted to any single machine of your choice but to run the application totally distributed over many heterogeneous machines out in the cloud.
 
High Availability and Fault Tolerance:
High availability of a process is achieved by replicating its state to another system in real time.
Because of the very design of AMPS, “state” is a clearly defined object that is maintained in real time and is the nerve centre of all the application and is the only object that needs to be replicated to provide high availability in case of a hardware failure of the primary server.
AMPS exposes specific APIs for this function. This is yet another benefit of the architecture of AMPS where high availability is available to all the applications written on AMPS without any further programmer intervention.
Debugging and performance tuning:
Every time an Event Handler starts or ends, the control comes to AMPS. This provides a central hub for the application to be monitored and debugged. It also gives the tester a unique insight into the actual state of things isolating all concurrency issues that have bugged the debuggers for years. AMPS exposes specific debugging, tracing and performance monitoring APIs that help in optimization and correctness of code.
Efficiency:
Since all deterministic code in AMPS runs without idle-wait or busy-wait locks and without any unnecessary context switching between threads, it saves considerable CPU time which is otherwise wasted in such activities.
Current CPUs have multiple levels of Cache. On multiple core systems, AMPS binds one thread to one core. This creates possibilities for maximum use of CPU cache for both instructions and data and generates significant improvements for quicker execution of same code. This is totally unlike multi-threaded system systems in which a thread usually changes cores tens of times in its life and each time it changes cores, both instruction and data cache need to be warmed again.