[mythtv-commits] mythtv commit: r22561 by cpinkham

mythtv at cvs.mythtv.org mythtv at cvs.mythtv.org
Thu Oct 22 04:17:58 UTC 2009


      Author: cpinkham
        Date: 2009-10-22 04:17:57 +0000 (Thu, 22 Oct 2009)
New Revision: 22561
   Changeset: http://cvs.mythtv.org/trac/changeset/22561

Modified:

   trunk/mythtv/libs/libmythdb/mythdbcon.h
   trunk/mythtv/libs/libmythdb/mythversion.h

Log:

Make MSqlQuery's prepareLock non-static as discussed on IRC.

This lock was originally put in a long time ago to hande the fact
that QSqlQuery::prepare() was not thread safe in Qt versions prior
to v3.3.2.  The Qt v4 version is thread safe.  We have seen issues
with deadlocks in mythbackend due to this lock, so we are removing
the static so that different threads do not lock each other trying
to prepare a query.  If there are no issues seen after the lock is
made non-static, we'll commit a larger patch which removes the
prepareLock totally.

The issue causing the deadlock currently is with the recorded table
and in IRC, we've been able to reproduce this with current trunk.
Here is the description of the one situation we've been able to
reproduce with 2 concurrent recordings.

Thread #1 calls programinfo.cpp's insert_program.  insert_program
gets a MySQL table write lock on the recorded table. insert_program
then performs a select on the recorded table.

While Thread #1 is performing the select, Thread #2 issues a
MSqlQuery::prepare() call in order to update the recorded table.
Thread #2 gets our MSqlQuery::prepareLock.  MSqlQuery::prepare()
in turn calls QSqlQuery::prepare which calls the MySQL prepare
function.  MySQL sees that the recorded table is locked for write
and locks Thread #2 waiting for the write lock to be released.

Meanwhile, Thread #1 finishes its select on the recorded table and
goes to perform an insert to insert the information for the new
recording.  It tries to MSqlQuery::parepare() the query, but locks
trying to get the prepareLock lock.  Now we have a deadlock.
Thread #1 is waiting on Thead #2 to unlock prepareLock and Thread #2
is waiting on Thread #1 to unlock the recorded table.

This does update the binary api version so make clean. It might not
have been totally necessary, but you had to recompile anyway because
of my previous [22560] commit.

Refs #7046






More information about the mythtv-commits mailing list