Bug #53204 os_fastmutex_trylock is implemented incorrectly on Windows

• Submitted: 27 Apr 2010 14:17
• Modified: 24 Aug 2010 18:46
• Reporter: Vladislav Vaintroub
• Status: Closed
• Category: MySQL Server: InnoDB storage engine
• Severity: S3 (Non-critical)
• Version: 5.1+
• OS: Windows
• Assigned to: Calvin Sun
• CPU Architecture: Any

[27 Apr 2010 14:17] Vladislav Vaintroub

Description:
os_fastmutex_try_enter() is implemented incorrectly.
It should be TryEnterCriticalSection rather than EnterCriticalSection.

EnterCriticalSection will block until critical section is available, while TryEnter  won't.

So current implementation blocks unnecessarily, which has a performance impact.
(if you need to just lock the mutex with waiting, there is os_fastmutex_enter for it)

See msdn documentation for the description of both functions.

How to repeat:
Examine source code.

[27 Apr 2010 17:07] Sveta Smirnova

Thank you for the report.

Which tree do you use. Is os_fastmutex_try_enter correct method name?

[27 Apr 2010 17:18] Valeriy Kravchuk

Verified by code review (quote from 5.1):

/**************************************************************
Acquires ownership of a fast mutex. Currently in Windows this is the same
as os_fast_mutex_lock! */
UNIV_INLINE
ulint
os_fast_mutex_trylock(
/*==================*/
                                                /* out: 0 if success, != 0 if
                                                was reserved by another
                                                thread */
        os_fast_mutex_t*        fast_mutex)     /* in: mutex to acquire */
{
#ifdef __WIN__
        EnterCriticalSection(fast_mutex);

        return(0);
#else
...

[27 Apr 2010 17:22] Vladislav Vaintroub

Oops, sorry, mixed trylock and try_enter, the function name is 
os_fast_mutex_trylock() of course

[29 Apr 2010 23:40] Omer Barnir

triage: need e/r value to see if can be done in 5.1  (i2 - as windows is a priority)

[4 Aug 2010 7:50] Bugs System

Pushed into mysql-trunk 5.5.6-m3 (revid:[e-mail]-20100731131027-1n61gseejyxsqk5d) (version source revid:[e-mail]-20100731074942-o840woifuqioxxe4) (merge vers: 5.5.6-m3) (pib:18)

[4 Aug 2010 8:06] Bugs System

Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804080001-bny5271e65xo34ig) (version source revid:[e-mail]-20100731075120-qz9z8c25zum2wgmm) (merge vers: 5.6.99-m4) (pib:18)

[4 Aug 2010 8:22] Bugs System

Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804081533-c1d3rbipo9e8rt1s) (version source revid:[e-mail]-20100731075120-qz9z8c25zum2wgmm) (merge vers: 5.6.99-m4) (pib:18)

[4 Aug 2010 9:02] Bugs System

Pushed into mysql-next-mr (revid:alik@ibmvm-20100804081630-ntapn8bf9pko9vj3) (version source revid:[e-mail]-20100731075120-qz9z8c25zum2wgmm) (pib:20)

[24 Aug 2010 18:46] Paul DuBois

Noted in 5.5.6, 5.6.0 changelogs.

Misimplementation of the os_fast_mutex_trylock() function in InnoDB
resulted in unnecessary blocking and reduced performance.