From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,1742659b6aa943fb X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!solnet.ch!solnet.ch!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Tasking and wxWidgets Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1132913111.023558.255590@g14g2000cwa.googlegroups.com> Date: Fri, 25 Nov 2005 12:37:47 +0100 Message-ID: <12gydxpbzl6wr$.u5gqms25vc8n.dlg@40tude.net> NNTP-Posting-Date: 25 Nov 2005 12:37:46 MET NNTP-Posting-Host: 1250ff42.newsread2.arcor-online.net X-Trace: DXC=Q@:>eA^7ED^fnCoe<@CEZ^Q5U85hF6f;TjW\KbG]kaMXA@_25la3nbRagb223H\TL[[6LHn;2LCV^7enW;^6ZC`T<=9bOTW=MN^ X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:6612 Date: 2005-11-25T12:37:46+01:00 List-Id: 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