Mailing List
Home
Forum Home
MySQL General - General MySQL discussion
MySQL++ - Programming with the C++ API to MySQL
MaxDB - Everything about MaxDB, formerly known as SAP DB
ODBC - ODBC with the MySQL Connector/ODBC driver
MySQL on Win32 - Runing MySQL on Windows 9x/Me/NT/2000/XP
Java Help - Mostly related to the MySQL Connector/J driver
Perl - Perl support for MySQL with DBI and DBD::mysql
GUI - MySQL GUI Tools
Announcement
Subjects
Subject: mysql openssl Question
ERROR 1045: Access denied for user: 'root@localhost ' (Using
password: NO)
Update one field with more fields from another table
Subject: Getting Identity after INSERT
ERROR 2002: Can 't connect to local MySQL server through socket
mysql test 4 1 fails with the gis test
Subject: MySQL Cluster Software
Downgrade Mysql from 4 to 3 23
Mysql 4 0 Oracle Stored Procedure Trigger Conversion
Can 't access mysql after kernel upgrade
Executing MySQL Commands From Within C Program
Comparing and writing out BLOBS
Subject: Re: Preventing Duplicate Entries
FULLTEXT query format question
Strange behavior, Table Level Permission
Does the binary log enabling affect the MySQL performances?
mysql:it 's a db not a dbms how it 's possible?!
mysql have same function mthod as Oracle decode()
 
Subject: Re: Sample files -- BadQuery w/Errnum patch part 4

Subject: Re: Sample files -- BadQuery w/Errnum patch part 4

2007-10-25       - By Warren Young

 Back
Jim Wallace wrote:
>> 2. Why does the first example need the loop?  The second pass
>> isn't actually needed to make it deadlock, is it?
> Not to get the deadlock, but to have it succeed, it must do the second
> pass

Okay, I just didn't understand that you want it to show both states,
success and failure.

There's an implied solution here that I wouldn't want to present in a
MySQL++ example, because that implies an endorsement.  The examples are
supposed to show good programming style and acceptable idioms.  "I'm
doing it like the examples" should never be a defense for bad code.

In a real program, looping is no fix for this problem, because you can't
know that a second try will always fix it.  The lock could be reacquired
by another program by the time you loop back around.  And putting the
whole thing in a while (1) or "for (i = 0; i < bignum; ++i)" loop isn't
any good either.

I think we don't want the example to succeed.  It's intentionally
demonstrating a programming bug, so it should fail.

> problem is that deadlock2 hangs waiting for the lock 1.  Once deadlock1
> tries to get lock 2 (which deadlock2 has), it immediately gets the
> deadlock exception, and rolls back, releasing lock1 so deadlock2
> completes ok.  And after deadlock2 completes, deadlock1 can retry and
> succeed.

Okay, so it's like with regular mutexes, where the order of acquisition
matters.  Do it in the same order in all programs, and it can't
deadlock, yes?

If we get rid of the loop and maybe add another pause point, is the only
difference the order of lock acquisition?  If so, you could just add an
option to examples/cmdline.cpp to switch between the modes.  It could be
just a generic "mode switch" (-m?) taking an integer that means
something only to some programs.  To examples/deadlock, -m1 says to
acquire lock1 first, and -m2 lock2.  All other programs can ignore it
for now.  The value can go in a global variable, like dtest_mode.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:    http://lists.mysql.com/plusplus?unsub=mysql@(protected)