Exceptions and thread-safety

[Ioannis Gyftos]

I am developing a little utility for my desktop, and at some point I
have a 'worker' thread and a (main) GUI thread. Depending on
circumstances, on some rare cases I wanted to display a window, but
since i use the QT library, the window must be created from the main
thread. So I need the 'worker' thread to interrupt its work, notify
the main thread, the main thread to display it, and then restart the
whole process after user interaction.

The way I implemented this, is that I throw an exception which is
caught at the run() function of the worker thread, and then it
notifies the GUI thread (through the signal/slot mechanism which is
offtopic). So far this has worked nicely on my machine.

(Though I am not sure if this the best approach since it's for
personal use, but for academic reasons, if you have a better idea I am
more than happy to hear it ).

My question is, supposing I have multiple 'worker' threads and an
exception occurs, is this thread safe? I googled a bit, and found that
some compilers have thread-safety on exceptions, but some don't. What
does the standard say? I would like to maintain a little portability
on the major desktop OS, so even if only the major desktop compilers
support this it is acceptable.

 

[Victor Bazarov]

[..]
My question is, supposing I have multiple 'worker' threads and an
exception occurs, is this thread safe?

Unknown at this point, most likely implementation-specific.

I googled a bit, and found that
some compilers have thread-safety on exceptions, but some don't.

Pretty much reflects the state of things, I'd say.

What
does the standard say?

Nothing at this point. In the future it will say that the exception
is caught in the same thread that throws it.

I would like to maintain a little portability
on the major desktop OS, so even if only the major desktop compilers
support this it is acceptable.

It's hard to say much at this point. Asking in the forums for your
target compiler should clear up some things.

V

 

[Guest]

I am developing a little utility for my desktop, and at some point I
have a 'worker' thread and a (main) GUI thread. Depending on
circumstances, on some rare cases I wanted to display a window, but
since i use the QT library, the window must be created from the main
thread. So I need the 'worker' thread to interrupt its work, notify
the main thread, the main thread to display it, and then restart the
whole process after user interaction.

The way I implemented this, is that I throw an exception which is
caught at the run() function of the worker thread, and then it
notifies the GUI thread (through the signal/slot mechanism which is
offtopic). So far this has worked nicely on my machine.

(Though I am not sure if this the best approach since it's for
personal use, but for academic reasons, if you have a better idea I am
more than happy to hear it ).

The only thing that might change is the throwing of the exception. I am
not sure if you do it because further execution is not possible, or to
return to the run() function. If it is the latter you can skip the
throwing and just signal the slot from where you are.

My question is, supposing I have multiple 'worker' threads and an
exception occurs, is this thread safe? I googled a bit, and found that
some compilers have thread-safety on exceptions, but some don't. What
does the standard say? I would like to maintain a little portability
on the major desktop OS, so even if only the major desktop compilers
support this it is acceptable.

If I understand you correctly the exception is caught in the same thread
as it was thrown (I assume that the run() function is where the new
thread starts execution). So far you should be thread-safe (but since
the standard says nothing on the subject some wacky implementation is
possible). The problem is with the signal/slot mechanism which might be
thread-safe or not, a quick look in the Qt docs tells me that it should
be safe in Qt4 and onwards (see the docs about the QObject::connect()
method, especially the last argument), for Qt3 you need to do some research.

 

[Ioannis Gyftos]

Thank you for your replies, they are right on target.

I was afraid of this, since I hear the C++ standard is not thread-
aware. So, I will try to work this around a bit.

I am not sure if you do it because further execution is not possible, or to
return to the run() function.

Further execution would have to stop and wait for user input, which
means returning to run(), so I guess both? I could not-throw and
return() all the way to the run() function (though currently it is a
rather big nest of void functions, and such a change would probably
require result codes etc, non-trivial work), so an exception was
easier to do. More importantly, though, I (thought I) wanted the
'worker' thread to have stopped its work before the signal is emitted
(but thinking back, I am not sure if it's that bad). If I pass the
parameters of the signal to the run() somehow, that would make the
function declarations unclean i guess (I pass those parameters inside
the exception now). And yes, I did check that Qt4's (which i use)
signal/slot mechanism is safe on threads.

I know it's a rather bad design, but I was not aware of the fact that
all Qt GUI must drawn at a specific thread when I started this

 

[James Kanze]

I was afraid of this, since I hear the C++ standard is not
thread-aware. So, I will try to work this around a bit.

Most implementations today are, however; the exact guarantees
vary, but should be sufficient to allow simultaneously throwing
an exception in two different threads. This was not necessarily
the case a few years ago, however---g++ 2.85.2, for example, was
*not* thread aware, and did have problems when two threads threw
an exception at the same time.

[...]

I know it's a rather bad design, but I was not aware of the
fact that all Qt GUI must drawn at a specific thread when I
started this

Isn't that a restriction in all GUI libraries? The usual
solution is to convert the request to some sort of GUI request,
on the GUI event queue, and have the GUI send you a message back
when the request was handled.

 

[Ioannis Gyftos]

Isn't that a restriction in all GUI libraries? The usual

solution is to convert the request to some sort of GUI request,
on the GUI event queue, and have the GUI send you a message back
when the request was handled.

I wouldn't know.

When I started that little project, I used Qt3.3 and the initial code
worked (maybe out of luck? dunno). Then I chose to convert to Qt4.2
and it broke, so I had to separate the GUI and the other process. Not
that I complain, as it does make more sense (as in model/view
architecture etc).