diff options
author | unknown <knielsen@knielsen-hq.org> | 2009-11-16 21:49:51 +0100 |
---|---|---|
committer | unknown <knielsen@knielsen-hq.org> | 2009-11-16 21:49:51 +0100 |
commit | a962160eec233c265900e2754ed2a63ef5e27c5a (patch) | |
tree | f1b33a7aed53016189b17cd3f50243b3c8a022de /mysys/thr_lock.c | |
parent | 166e0683c0d45a79716d8913ec9ecaf3177343fa (diff) | |
parent | 9b7a7f06c1a56f49a4528f019ec821d3a01934b6 (diff) | |
download | mariadb-git-a962160eec233c265900e2754ed2a63ef5e27c5a.tar.gz |
Merge with MySQL 5.1, with following additions:
- Moved some code from innodb_plugin to xtradb, to ensure that all tests runs
- Did changes in pbxt and maria storage engines becasue of changes in thd->query
- Reverted wrong code in sql_table.cc for how ROW_FORMAT is used.
This is a re-commit of Monty's merge to eliminate an extra commit from
MySQL-5.1.42 that was accidentally included in the merge.
This is a merge of the MySQL 5.1.41 clone-off (clone-5.1.41-build). In
case there are any extra changes done before final MySQL 5.1.41
release, these will need to be merged later before MariaDB 5.1.41
release.
Diffstat (limited to 'mysys/thr_lock.c')
-rw-r--r-- | mysys/thr_lock.c | 22 |
1 files changed, 22 insertions, 0 deletions
diff --git a/mysys/thr_lock.c b/mysys/thr_lock.c index 3eabde85a58..c830c4ed0cc 100644 --- a/mysys/thr_lock.c +++ b/mysys/thr_lock.c @@ -420,6 +420,28 @@ wait_for_lock(struct st_lock_list *wait, THR_LOCK_DATA *data, my_bool can_deadlock= test(data->owner->info->n_cursors); DBUG_ENTER("wait_for_lock"); + /* + One can use this to signal when a thread is going to wait for a lock. + See debug_sync.cc. + + Beware of waiting for a signal here. The lock has aquired its mutex. + While waiting on a signal here, the locking thread could not aquire + the mutex to release the lock. One could lock up the table + completely. + + In detail it works so: When thr_lock() tries to acquire a table + lock, it locks the lock->mutex, checks if it can have the lock, and + if not, it calls wait_for_lock(). Here it unlocks the table lock + while waiting on a condition. The sync point is located before this + wait for condition. If we have a waiting action here, we hold the + the table locks mutex all the time. Any attempt to look at the table + lock by another thread blocks it immediately on lock->mutex. This + can easily become an unexpected and unobvious blockage. So be + warned: Do not request a WAIT_FOR action for the 'wait_for_lock' + sync point unless you really know what you do. + */ + DEBUG_SYNC_C("wait_for_lock"); + if (!in_wait_list) { (*wait->last)=data; /* Wait for lock */ |