Re: Tasking and wxWidgets

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 25 Nov 2005 02:05:11 -0800, Lucretia wrote:

> 1) Is there any situation where having multiple threads with it's own
> (or shared) GUI makes sense? Can anybody actually think of any examples
> where, say, a frame has multiple threads and they all (or some) want to
> update the GUI?
> 
> As an example, say you have an monitoring application which has on it a
> number of controls, e.g. temperature, pressure guages, It would be
> possible to set up two threads which monitor the actual sensors and
> send events directly to the temperature/pressure wxGuage controls.
>
> Another example would be to provide a log window in which error
> messages from these same sensors could be dumped, in this case the
> wxEvtHandler derived class is accessed by two different threads
> concurrently and would need t synchronised.

Yes both is the case for HMIs (human-machine interface) used to control
some large test system (like a dynamometer.) But it is only one side of the
issue. Another is the actions invoked by the GUI. If an action is
synchronous (that's you cannot continue), and it is often the case, then
with a single-thread design you block the whole GUI. Now, imagine, the
operator starts daily log print, which is busy opening that idiotic printer
properties dialog. Suddenly something gets wrong, really wrong ... and the
"emergency stop" button is dead.

> 2) I could also go the other way and inside the
> wx.Base.Object.Object_Type (wxObject) provide a mutex object, such that
> every call in wxAda would lock (on entry) and unlock (on exit) thus
> providing thread safety if that particular object were accessed via
> multiple tasks. The overhead of constructing/destructing a mutex locker
> object, locking/unlocking the mutex object on every call would be
> rather high and thus, would most probably slow the application down to
> a crawl (although, not tested). Use of inlining might make this nicer?

That depends on the architecture of the GUI system. I don't know wxWidgets.

In the GUI system we developed for HMIs, rendering and data feeding are
often separated. They have independent cycles and consequently are used
from different threads. Locking overhead was never a problem [well, I
presume, you aren't going to perform pixelwise image transformation.] We
often use a specialized "mutex" which allows parallel read access if there
is no any write access. It would be nice to use Ada's protected objects
here, because they basically have this functionality, but unfortunately 1)
the thing is in C++, 2) Ada's protected objects aren't OO composable, they
are not tagged.

You should also consider Ada tasks, which sometimes are more natural than
protected objects.

And more than two mutexes is a problem. You should try to make the API
composable without or minimal deadlock danger. For example, Windows GUI API
can deadlock, and often do.

> 4) Is it possible that the synchronisation code that *is* in the
> wxWidgets library (I'm not talking about the actual wxThread,
> wxSemaphore, etc. classes here, but the places where there is critical
> sections to protect concurrent access) could interfere with Ada's
> tasking and protected types (Ada's implementation of monitors)?

Very unlikely, IMO. [Provided, Ada run-time is using native threads.]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de