|Home||You are here: Home > Support > Reference v1.0|
Change language: German
Main Page | Modules | Namespace List | Class Hierarchy | Class List | Namespace Members | Class Members
Multithreadingexom::XmObject, exom::XmArray, exom::XmMan, exom::XmManFcn, exom::XmPath, exom::XmDialog, exom::XmUIDialog, exom::XmID, exom::XmString, exom::XmStreamIn and exom::XmStreamOut.
So it is no problem to operate on two or more instances of the same exom class in different threads without side effects. So the absence of using global data within the exom library support multithreading without the need of synchronization.
In addition to this application code may raise the need of using synchronization. Therefor the exom framework provide the synchronization class exom::XmLock. Currently the exom framework make usage of synchronization only in exom::XmDialog by proving a dialog lock.exom::XmDialog::SetDlgLock(). These dialog locks may be necessary for 'progress dialogs', which are typically implemented by a UI thread and a worker thread. If one of these threads accesses (read/write) shared application data, the operation have to be enclosed in a exom::XmLock::lock() and exom::XmLock::unlock() pair.
E.g. the exom Add-On exomWin32 use the dialog lock, if redrawing or updating the content of a dialog. Locking within the worker thread have to be done by the application, because only the application knows exactly the sections which have to be locked.
The technique of using a dialog lock for multithreading offer the possibilitly to be applied in different UI systems like GUI, console or webinterface, without changing application code.
Normally dialogs don't make usage of multithreading, so the default dialog lock is initialized by an instance of exom::XmNoLock to avoid synchronization overhead.
|Copyright © 2006 Praetz Software Development - www.exomware.com|