= Threading and the !SystemQueue =

Ariba makes it easy to avoid threading issues like synchronization and upcoming problems like deadlocks, race conditions, or access violations. The threading model in Ariba is completely serial, parallelism is avoided whenever possible. If you are using Ariba to write a service or application, two simple guidelines apply:

 * Code event driven
 * Don't block or wait

When you comply with these two points, you will never get into any threading problems!

== Overview of Threading in Ariba == 

Ariba runs one main thread, called the !SystemQueue. All events in Ariba originate the !SystemQueue, that means that all functionality is triggered by events that are placed into the !SystemQueue. As all functionality is triggerd through the !SystemQueue, only one thread exists in Ariba and you can be sure that all code always runs in sync. The concept of one main queue exists in several software projects, and in gernal is called [http://en.wikipedia.org/wiki/Event_loop Event loop]:

 * MS Windows uses one main thread in GUI applications (also called the ''main loop'') to schedule and execute GUI changes (details on this are available [http://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Windows here]. The {{{WinMain}}} function in Windows applications that are linked against the Windows Subsystem is such an event loop. It uses the Win32 API {{{GetMessage}}}, {{{TranslateMessage}}}, and {{{DispatchMessage}}} to implement serial message processing in Windows.
 * OMNeT++ has an ''event queue'' that completely handles execution of simulations (called [http://www.omnetpp.org/doc/api/classcScheduler.html cScheduler]. If you compile Ariba with simulation support, the !SystemQueue gets synchronized with the OMNeT++ event queue for seamless integration.
 * The X Windows System uses event queues in XLib and GLib.

== !SystemQueue Internals == 

== Using the !SystemQueue == 

== Using Blocking Code ==