Hi Sergei,
Sergei Golubchik, 17.03.2008 19:42:
> Hi!
>
> On Mar 17, Ingo Strüwing wrote:
>> Sergei Golubchik, 17.03.2008 16:12:
>> ...
>>> On Mar 12, Ingo Strüwing wrote:
>> ...
>>> How would you, without a global variable, synchronize with threads
>>> that are not connection threads ?
>> I didn't have it in mind when designing the feature. The use cases I
>> had in mind included connection threads only.
>>
>> Do you want to have it in the initial implementation? Or can we take
>> it as a potential extension for later?
>
> As you don't need it now apparently and Backup guys don't need it
> either, let us keep this idea as a potential extension for later.
>
> Could you add it as a @todo comment to sys_var_debug_sync::check, where you
> prevent updates to a global variable ?
Ok.
>
>> Possible problems with GLOBAL synchronization could be:
>>
>> - Every thread is affected, even the requesting one. Precautions must be
>> taken that only the right thread executes the action.
>
> Yes. But a special action IGNORE could help (works like ignore in gdb
> breakpoints).
You mean SET SESSION DEBUG_SYNC= 'sync_point IGNORE 5' as an 5-times
override for the global action in the current thread? (The gdb IGNORE
command affects all threads IMHO).
OTOH the purpose of the facility was to assure a predictable order of
execution of the threads. So one knows in advance, which threads run
through the sync point in which order. The IGNORE count in the real
action would cover all executions by threads that shall not execute the
action. That would make it like the gdb command. However, EXECUTE 2
would work only if no other thread executes the sync point in between.
Also it means that one must control all threads, not just a limited set
of threads.
I wonder if the complexity of synchronizing connectionless threads might
be smaller if it would be possible to set actions for a specific thread.
This raises the question how to retrieve the thread id of a
connectionless thread.
>
>> - Mikael told me that DBAs use to experiment with everything, even on a
>> production system. Blocking the own thread forever is bad enough, but
>> allowing for blocking everything sounds even worse.
>
> Remember that an action is removed when executed.
> To really block everything one needs to use EXECUTE N, with N > number
> of running threads.
Urks. I didn't think of this implication even. This means that global
sync point execution needs (partial) protection by a mutex. Unless one
can be sure to have full control of all threads.
An alternative idea would be to copy the global array at thread start.
Changes of the global array won't influence running threads then. This
would be in line with the behavior of some other system variables. But
it wouldn't make control of other threads more simple.
Regards
Ingo
--
Ingo Strüwing, Senior Software Developer
MySQL GmbH, Dachauer Str. 37, D-80335 München
Geschäftsführer: Kaj Arnö - HRB München 162140
