MySQL Bugs: #47396: Innodb accesses mysql server internal mutex LOCK_thread

Bug #47396	Innodb accesses mysql server internal mutex LOCK_thread_count
Submitted:	17 Sep 2009 7:45	Modified:	1 Dec 2009 12:16
Reporter:	Marc ALFF	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: Storage Engine API	Severity:	S1 (Critical)
Version:	5.4.3 (mysql-trunk)	OS:	Any
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
The innodb code contains, in ha_innodb.cc, the following code:

/* This is needed because of Bug #3596.  Let us hope that pthread_mutex_t
is defined the same in both builds: the MySQL server and the InnoDB plugin. */
extern MYSQL_PLUGIN_IMPORT pthread_mutex_t LOCK_thread_count;

This code accesses a mutex that should be private to the server.

There are no guarantees that LOCK_thread_count really is a pthread_mutex_t,
as the comment states.

In particular, in 5.4, LOCK_thread_count will change to a different type,
to instrument waits on LOCK_thread_count for the performance schema.

How to repeat:
Read the code

Suggested fix:
Expose an API to lock / unlock LOCK_thread_count from the server,
and use that API from ha_innodb.cc

This way, the real implementation and type of LOCK_thread_count will be hidden,
while maintaining the work around for bug#3596

Verified by code review.

will be fixed in WL#5134

Why not an 'instrument' service? 

s->increase_thread_count();
s->decrease_thread_count();
s->reset_thread_count();
..
s->reset_all_measurements();
..
s->tick();
..
s->tick();
..
s->aggregate_ticks();

A 'mutex' doesn't do anything. It is a building block for a layer far below the high level implementation a storage engine hooks into. It isn't efficient communication. An API should provide a help for the user to avoid making mistakes. There is no such help provided in a mutex because it can be used in very many ways.

If we indeed need to intercept the pthread library we could use the same technique as we do with malloc on OpenSolaris or Linux (google version).

will be fixed as a part of bug#38883