statement being KILLed".

When statement which was trying to obtain write lock on then table and
which was blocked by existing read lock was killed, concurrent statements
that were trying to obtain read locks on the same table and that were
blocked by the presence of this pending write lock were not woken up and
had to wait until this first read lock goes away.

This problem was caused by the fact that we forgot to wake up threads
which pending requests could have been satisfied after removing lock
request for the killed thread.

The patch solves the problem by waking up those threads in such situation.

Test for this bug will be added to 5.1 only as it has much better
facilities for its implementation. Particularly, by using I_S.PROCESSLIST
and wait_condition.inc script we can wait until thread will be blocked on
certain table lock without relying on unconditional sleep (which usage
increases time needed for test runs and might cause spurious test
failures on slower platforms).


mysys/thr_lock.c:
  After removing lock request from the list of waiting lock requests
  (e.g. when we discover that current thread was killed) we should
  wake up other threads waiting for the same lock which pending
  requests now can be satisfied. To implement this behavior we
  move code responsible for waking up threads which pending requests
  can be satisfied from thr_unlock() to new wake_up_waiters() procedure
  and use it in wait_for_lock() and hr_abort_locks_for_thread().