[Qt-interest] Fwd: ASSERT failure in QMutex::unlock(): "A mutex must be unlocked in the same thread that locked it."

[Oluwafemi Ade]

---------- Forwarded message ----------
From: Oluwafemi Ade <oamaximpact at gmail.com>
Date: Fri, Jul 16, 2010 at 11:37 PM
Subject: Re: [Qt-interest] ASSERT failure in QMutex::unlock(): "A mutex must
be unlocked in the same thread that locked it."
To: Sean Harmer <sean.harmer at maps-technology.com>




On Fri, Jul 16, 2010 at 2:24 PM, Sean Harmer <
sean.harmer at maps-technology.com> wrote:

> On 16/07/2010 17:36, Sarvesh Saran wrote:
> > Hi,
> >
> > Sorry for the poor indentation. Let me rephrase:
> >
> > I am simply having a tough time understanding how signals and slots work
> across threads.
> >
> > Assume that I have a MyThread:QThread object called A running and it
> contains a public slot setValue().
> >
> > //this code is in the main window
> > MyThread *a = new MyThread; //create the thread
> > connect(this,sendValue(int),a,setValue(int)));
> >
> > later in the code I emit a signal:
> > emit sendValue(10);
> >
> > I would like to know how this emit is different from:
> > a->setValue(10) ?
> >
> > in either case, who executes the slot setValue? Is it the MainWindow
> thread  or MyThread?
>
> The slot gets executed in the thread that calls a->setValue(10) and emit
> sendValue(10), the main thread in your case.
>
> This is because the QThread object has affinity with the main thread
> because that is where it was created.
>
> To ensure that your slot gets executed in the context of yoru worker
> thread, you should not put the slot on the QThread object itself, but
> rather create a new helper object derived from QObject (with 0 for the
> parent) in the run() function of your thread class.
>
> This new QObject will have affinity with the worker thread because that
> is the context in which it was created.
>
> So now if you make a connection between a signal from an object that has
> affinity with the main thread (your mainwindow object for example) and a
> slot on the new helper object in your worker thread, the default
> connection mode of Qt::AutoConnection will determine that Qt should use
> a queued connection for this case. [In actual fact the decision is
> deferred until you emit the signal since objects can change thread
> affinity with the moveToThread() call].
>
> For your worker thread to be able to deliver the event that is used to
> implement queued connections, you must ensure that you start the event
> loop by calling QThread::exec() within the run() function. Without this,
> your helper QObject that lives in the worker thread will not have its
> slot called.
>
> In summary, it is best to consider QThread purely as a means of
> launching another thread, not as the object that does any real work in
> that thread (unless you do not need the worker thread to be event driven
> of course as illustrated in the Mandelbrot example). Much better to
> create QObjects within the worker thread to do the work instead.
>
> HTH,
>
> Sean
>
>

   Hi.......clear explanation. I have a similar issue, the QThread lives in
the main thread, it was created there, so we create a QObject subclass in
run and make connections with the QThread subclass and call exec() to make
the worker event driven.  In my case I want the worker to help send a
QByteArray to some server, hence I pass a QByteArray, a QTcpSocket, (a
QObject = 0 as its parent in its .h file) to the worker's constructor in
run(), which it installs as private variables, also in run() before calling
exec I call, connectToHost() on the passed socket, so that part of the
connections made is for the workers sendData() function to be called when
the socket emits connected(), which actually gets called. But I found out
that write() on the socket in the workers sendData() is not seen by the
server, though inComingConnection() was seen on the server which triggered
the worker's sendData() anyways............is there something missing?

> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100716/7015f858/attachment.html