Qt-interest Archive, March 2002
Horrible threads...
Message 1 in thread
Lets start from the beginning... I have a keylock-thread which periodly
looks for a keylock. If it finds one, it emits a signal keyChanged(QString).
This signal is catched within a dll/shlib and sets the current String to
the given parameter.
The main application does its stuff and calls also functions within the
dll which are looking if the current key has a correct value.
- I think I have to have a QMutex when I am doing both, looking for the
key and set it, right? Then there is the question, do I have to call it
with QMutex(TRUE) or FALSE for recursion?
- When the signal is catched, then I am in the workspace of the second
(not-main-) thread? So I have to call QMutex(TRUE)?
- QString itself is not thread-safe itself, sprintf is forbidden... ok.
I use QString::number to build a number, but can I use QString at all in
this way?
when I am using non-recursive threads then main app blocks forever, so I
think TRUE would be right. But I am not sure, I can not debug it as I
want to... I only can hope that everything is correct :-(
Can't we return to the good ol' dos? Without preemptive what-so-ever and
everything? It was the most stable system (if you didnt have a stack
overflow of course)...
Message 2 in thread
On Friday 01 March 2002 10:14 am, Jörg Preiß wrote:
> Lets start from the beginning... I have a keylock-thread which periodly
> looks for a keylock. If it finds one, it emits a signal
> keyChanged(QString). This signal is catched within a dll/shlib and sets the
> current String to the given parameter.
> The main application does its stuff and calls also functions within the
> dll which are looking if the current key has a correct value.
>
> - I think I have to have a QMutex when I am doing both, looking for the
> key and set it, right?
Right.
> Then there is the question, do I have to call it
> with QMutex(TRUE) or FALSE for recursion?
It sounds like you do not want a recursive mutex.
> - When the signal is catched, then I am in the workspace of the second
> (not-main-) thread? So I have to call QMutex(TRUE)?
I don't see why. You only need a recursive mutex if you want to nest
lock/unlock regions in a single thread. Which IMO, is rarely useful and may
indicate that you need to rethink your design.
> - QString itself is not thread-safe itself, sprintf is forbidden... ok.
> I use QString::number to build a number, but can I use QString at all in
> this way?
Sprintf is not the only non-thread-safeness in QString. If you access a
string object from multiple threads you must do two things:
1) Synchronize access with a mutex when getting or setting the value.
2) Use deep copies when getting or setting a value.
Failing to do #2 can cause infrequent but baffling failures.
> when I am using non-recursive threads then main app blocks forever, so I
> think TRUE would be right. But I am not sure, I can not debug it as I
> want to... I only can hope that everything is correct :-(
I would suspect that the problem is not that you should be using recursive
threads, but that you are using non-recursive threads improperly.
FWIW, I prefer passing simple values like this between threads by sending
events via QThread::postEvent(). QString caveats still apply when doing this.
-K
