Re: Tasking and wxWidgets

["Lucretia" <lucretia9@lycos.co.uk>]

Dmitry A. Kazakov wrote:
> On 25 Nov 2005 02:05:11 -0800, Lucretia wrote:
>
> 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.

Hmm, but if each wxAda type had it's own mutex, surely you'd only end
up locking that particular object at any one time?

> > 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.

Yeah.

> 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

It's a possibility if somebody wanted to create an image manipulation
program with wxAda?!

> 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.

Exactly, and getting multiple objects using protected objects is
impossible, unfortunately.

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

Still would be impossible to do, this is why I was considering leaving
the library as non-thread-safe and allowing the application developer
to handle concurrency issues.

> 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

I'm not sure what you mean about "composable without or minimal
deadlock danger"

> 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.]

Yeah, I know that the RTS uses native threads...This is what I thought,
I just needed to be sure.

Thanks,
Luke.