Hi!
>>>>> "Yuri" == Yuri Dario <mc6530@stripped> writes:
Yuri> Hi Monty,
>> Note the --send command; This tells MySQL to just send the command
>> but not wait for the commend to execute.
>>
>> You could try to increase the 'sleep' time to 3 seconds to check if
>> this is a bug in the thread scheduler on OS/2.
Yuri> now it works, but I don't understand why. Could you explain what's
Yuri> happening?
Yuri> After your mail, I went back to my_lock code: I this situation, OS/2 is
Yuri> setting the lock using MY_HOW_OFTEN_TO_ALARM as timeout (default is 2
Yuri> seconds).
Yuri> Seems that 'sleep 0.5' is too fast for such time out; and a sleep
Yuri> longer that 1.999 will give a successfull test.
Yuri> Do I have to set a lower timeout?
The problem should not be the timeout, because the wait should not
happen in the OS lock code.
What should happen:
con1 and con2 are two connections that runs on two separate threads in MySQL.
- con1 gets a read lock on table t1
- con2 tries to get a lock with the 'update t1...' command.
This should block in thr_lock() because con1 has already a lock on
the table.
The above update command is sent in not blocking mode to the server, so
the client can issue an unlock to con1, which should send a
condition signal to con2 that it can get the lock.
One thing that does happen is this:
- con1 sets a OS read lock on the table
- Before calling thr_lock() con2 tries to change the read lock on the
index file to a write lock.
It could be a bug that you can't change a read lock to a write lock
from another thread. On Windows and Linux this works without any
problem, as it's the process that has the lock, not the threads.
The only reason for MySQL to get the lock at all is to allow other
programs to work on the same tables. As this is something most users
never have to do anymore, now when we have CHECK and REPAIR inside
MySQL, I think you can just define that we should always use
--skip-locking on OS2.
Regards,
Monty
