From: Ingo Strüwing
Date: March 5 2010 10:46am
Subject: Re: bzr commit into mysql-5.1-bugteam branch (aelkin:3369) Bug#51648
List-Archive: http://lists.mysql.com/commits/102418
Message-Id: <4B90E11A.7010004@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

Hi Luís,

Luís Soares, 05.03.2010 02:37:

...
> I wish we could go further than just setting globally. IIUIC, setting
> it globally for non-connection threads, means that we only have control
> over the actions at one specific point in time (before the thread is
> started). We can't do nothing wrt the list of actions later! But I want
> to have this  ;) . 


Agree. That would be nice to have. But that means that a thread wants to
modify another thread's local storage while that thread might just be
reading it. Mutex protection would be mandatory. In turn this means that
every sync point in the code would do a mutex lock and unlock. Once in a
sudden sync point activity would have a measurable impact on server
performance. :(

Also, sync points might begin to introduce some sort of synchronization
in general, even when no action is set for them. Mutex operation may
have side effects like a stall of the thread operation for a flush of
the processor write queue or such.

For these reasons I'd like to avoid mutex handling in sync points.
Hence, the thread-owned actions can't be modified by another thread on
the fly.

I can think of two compromises:

A) Sync points are optimized to have as little impact as possible. (One
compromise has been made for "usability" though.) Their first operation
is to check if the facility is enabled at all. Only then they scan
through the actions. At this point they could do a second check: If
cross thread activation is enabled. Only then they would take a mutex
before scanning the actions. The test cases, which require system thread
synchronization would set a command line option.

B) System threads usually run in a loop. After performing some task,
they usually wait for instructions. After such waits, they could enter
some new debug_sync_* function in which they look for new debug_sync
actions and integrate them into their private action list. Other threads
would send sync point activations for system threads into a queue, where
these pick them up after their above mentioned wait.

In any case, a syntax extension for the SET DEBUG_SYNC= string would be
required. Also a feasible way to identify threads would be required.

Regards
Ingo
-- 
Ingo Strüwing, Database Group
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schröder, Wolfgang Engels
Vorsitzender des Aufsichtsrates: Martin Häring   HRB München 161028