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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham 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!postnews.google.com!f14g2000cwb.googlegroups.com!not-for-mail From: "Lucretia" Newsgroups: comp.lang.ada Subject: Re: Tasking and wxWidgets Date: 26 Nov 2005 09:34:37 -0800 Organization: http://groups.google.com Message-ID: <1133019814.811981.158580@f14g2000cwb.googlegroups.com> References: <1132913111.023558.255590@g14g2000cwa.googlegroups.com> <12gydxpbzl6wr$.u5gqms25vc8n.dlg@40tude.net> NNTP-Posting-Host: 194.74.199.42 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1133026481 3258 127.0.0.1 (26 Nov 2005 17:34:41 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 26 Nov 2005 17:34:41 +0000 (UTC) User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1),gzip(gfe),gzip(gfe) X-HTTP-Via: 1.0 Symantec_Web_Security (3.0.1.74), 1.0 C2100-0050414028 (NetCache NetApp/5.5R5) Complaints-To: groups-abuse@google.com Injection-Info: f14g2000cwb.googlegroups.com; posting-host=194.74.199.42; posting-account=G-J9fgwAAADgpzBiEyy5tO4f8MX5fbpw Xref: g2news1.google.com comp.lang.ada:6640 Date: 2005-11-26T09:34:37-08:00 List-Id: 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.