Re: Tasking and wxWidgets

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

On 26 Nov 2005 09:26:17 -0800, Lucretia wrote:

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

Depends on what is the object here, and what is allowed to do with a mutex
taken. If there is a possibility to perform blocking actions within other
actions, then be ready for hell. One way to get out of this is to remove
mutexes from objects and pass them as parameters or discriminants. Another
is to use monitor tasks.

>> 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?!

Do you ask me? (:-)) Look at absolutely useless Window's SetPixel. Then
you'll need double buffering and all that stuff. 

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

Hmm, do you mean multiple protected actions here?

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

You should separate it into safe and unsafe parts. You don't need
thread-safe String, you probably need safe Show_Text.

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

From the messages loop [in a deeply nested callback subprogram] you spin
for a mutex held by another thread that does SetWindowText to the window.
Here you are.

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