* Re: Tasking and wxWidgets
2005-11-25 11:37 ` Dmitry A. Kazakov
@ 2005-11-26 17:26 ` Lucretia
2005-11-27 11:15 ` Dmitry A. Kazakov
2005-11-26 17:26 ` Lucretia
` (2 subsequent siblings)
3 siblings, 1 reply; 19+ messages in thread
From: Lucretia @ 2005-11-26 17:26 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Tasking and wxWidgets
2005-11-26 17:26 ` Lucretia
@ 2005-11-27 11:15 ` Dmitry A. Kazakov
2005-11-28 10:48 ` Lucretia
0 siblings, 1 reply; 19+ messages in thread
From: Dmitry A. Kazakov @ 2005-11-27 11:15 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Tasking and wxWidgets
2005-11-27 11:15 ` Dmitry A. Kazakov
@ 2005-11-28 10:48 ` Lucretia
2005-11-28 14:41 ` Dmitry A. Kazakov
0 siblings, 1 reply; 19+ messages in thread
From: Lucretia @ 2005-11-28 10:48 UTC (permalink / raw)
> > 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.
The object could be any of the wx objects, a wxFrame, wxButton,
wxToolBar, wxStatusBar, etc.
> > 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.
No! I mean't it is possible that somebody would want to.
> >> 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?
No! I mean you cannot create derivable types from protected types. The
wxAda hierarchy matches that of the C++ wxWidgets hierarchy. wxObject
(wx.Base.Object.Object_Type) is the base type and everything derives
from there. wxEvtHandler (wx.Base.Event_Handler.Event_Handler_Type)
derives from wxObject. wxWindow derives from wxEvtHandler. wxControl
derives from wxWindow. etc.
So, how do you make this thread safe? All controls are windows and all
events go through the event handler classes. In the wxWidgets library
there is minimal thread safe code in the event handling code, but do I
want to make a completely thread safe library or leave it up to the
application developer?
> >> 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.
Eh?
Thanks,
Luke.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Tasking and wxWidgets
2005-11-28 10:48 ` Lucretia
@ 2005-11-28 14:41 ` Dmitry A. Kazakov
0 siblings, 0 replies; 19+ messages in thread
From: Dmitry A. Kazakov @ 2005-11-28 14:41 UTC (permalink / raw)
On 28 Nov 2005 02:48:26 -0800, Lucretia wrote:
> The object could be any of the wx objects, a wxFrame, wxButton,
> wxToolBar, wxStatusBar, etc.
This is rather a "visual" hierarchy, i.e. things are arranged on the
screen. But how does it work. Does wxButton send a message to wxFrame, or
wxFrame queries wxButton for its state, or maybe wxButton has On_Click
abstract method to override etc.
> No! I mean you cannot create derivable types from protected types.
Yes. However you can:
type Protected_Action is abstract tagged ...
procedure Perform (What : in out Protected_Action) is abstract;
protected type Subject is
entry Request (What : in out Protected_Action'Class);
...
protected body Subject is
entry Request (What : in out Protected_Action'Class) ... is
begin
Perform (What); -- Dispatches
end;
Yet, it would be a very bad idea to perform rendering from a protected
action.
> wxAda hierarchy matches that of the C++ wxWidgets hierarchy. wxObject
> (wx.Base.Object.Object_Type) is the base type and everything derives
> from there. wxEvtHandler (wx.Base.Event_Handler.Event_Handler_Type)
> derives from wxObject. wxWindow derives from wxEvtHandler. wxControl
> derives from wxWindow. etc.
Does wxEvtHandler encapsulate a thread?
> So, how do you make this thread safe? All controls are windows and all
> events go through the event handler classes. In the wxWidgets library
> there is minimal thread safe code in the event handling code, but do I
> want to make a completely thread safe library or leave it up to the
> application developer?
I will be difficult if possible in thin bindings if the library design
wasn't thread safe.
>>>> 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.
>
> Eh?
The messages loop waits for the mutex. The thread holding the mutex waits
for SendMessage to return the result. Deadlock.
Things like this happen. [ The design problem is that rendering actions
(like SetWindowText) and semantic actions (potentially lengthy and
serialized) are served by the same thread. ]
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Tasking and wxWidgets
2005-11-25 11:37 ` Dmitry A. Kazakov
2005-11-26 17:26 ` Lucretia
@ 2005-11-26 17:26 ` Lucretia
2005-11-26 17:28 ` Lucretia
2005-11-26 17:34 ` Lucretia
3 siblings, 0 replies; 19+ messages in thread
From: Lucretia @ 2005-11-26 17:26 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Tasking and wxWidgets
2005-11-25 11:37 ` Dmitry A. Kazakov
2005-11-26 17:26 ` Lucretia
2005-11-26 17:26 ` Lucretia
@ 2005-11-26 17:28 ` Lucretia
2005-11-26 17:34 ` Lucretia
3 siblings, 0 replies; 19+ messages in thread
From: Lucretia @ 2005-11-26 17:28 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Tasking and wxWidgets
2005-11-25 11:37 ` Dmitry A. Kazakov
` (2 preceding siblings ...)
2005-11-26 17:28 ` Lucretia
@ 2005-11-26 17:34 ` Lucretia
3 siblings, 0 replies; 19+ messages in thread
From: Lucretia @ 2005-11-26 17:34 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 19+ messages in thread