Qt-interest Archive, April 2007
Signals and Slots vs Mutex
Message 1 in thread
Hi everybody,
I started to develop a server client application with Qt.
I am using QThreads and thought about thread safety.
On the one hand i thought i can use signals and slots with
queueed connections, on the other hand i have QMutex.
The question is which one is better for the performance
under heavy load.
Signals and slots:
Pro:
Easier to use
Contra:
10 funktion calls are used to send a signal
We need 2 signals back and for
I am not sure about the performance for a queue with 100-300 signals per
second, i think not so good
QMutex:
Pro:
Not so much funktion calls
Not 2 signals because of the return parameter
Contra:
Im not sure but i think that there is a signals back to tell a waiting
thread that the mutes it is unlocked
I hope someone can help me to judge this
--
[ signature omitted ]
Message 2 in thread
On Apr 12, 2007, at 1:37 PM, Don-Calzone wrote:
> I started to develop a server client application with Qt.
> I am using QThreads and thought about thread safety.
>
> On the one hand i thought i can use signals and slots with
> queueed connections, on the other hand i have QMutex.
> The question is which one is better for the performance
> under heavy load.
>
> Signals and slots:
> Pro:
> Easier to use
> Contra:
> 10 funktion calls are used to send a signal
> We need 2 signals back and for
> I am not sure about the performance for a queue with 100-300
> signals per second, i think not so good
>
> QMutex:
> Pro:
> Not so much funktion calls
> Not 2 signals because of the return parameter
> Contra:
> Im not sure but i think that there is a signals back to tell a
> waiting thread that the mutes it is unlocked
>
> I hope someone can help me to judge this
For the signal/slot approach, keep in mind that you should structure
things such that you do NOT keep firing a signal each time an event
occurs in your producer thread. Instead, fire once and then somehow
reset when the consumer thread is able to respond to the queued
signal. In a high-traffic network application (thousands of
messages / second) I have, I was swamping my event queue with these
queued notifications. With a one-shot approach, I'm running fine.
Also, see if you can get by with sending no data in your signals. In
my application, my reader thread sends a signal that data is
available, but it still continues to accumulate data in a vector
until the other thread finally gets to fetching the messages, at
which time, under the protection of a mutex, I swap some indices, and
release the mutex. The reader thread resumes appending to a different
vector, while the processing thread can safely work with the vector
that had been in use by the reader thread.
For the second case, instead of listening for some unlock signal, use
a condition variable to detect when there is data available. See Qt's
examples. This is the classic consumer/producer situation. People use
mutexes, semaphores, or circular buffers without any locking to
safely handle data exchanges among threads.
Brad
--
[ signature omitted ]
