[mythtv-commits] Ticket #7046: libmysql deadlock

[MythTV]

#7046: libmysql deadlock
---------------------------------------------+------------------------------
 Reporter:  David Asher <asherml@…>          |        Owner:  danielk
     Type:  defect                           |       Status:  closed 
 Priority:  major                            |    Milestone:  0.22   
Component:  MythTV - General                 |      Version:  head   
 Severity:  medium                           |   Resolution:  invalid
  Mlocked:  0                                |  
---------------------------------------------+------------------------------

Comment(by cpinkham):

 (In [22561]) 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

-- 
Ticket URL: <http://svn.mythtv.org/trac/ticket/7046#comment:12>
MythTV <http://www.mythtv.org/>
MythTV