List:Commits« Previous MessageNext Message »
From:Ingo Strüwing Date:March 18 2008 8:43am
Subject:Re: bk commit into 6.0 tree (istruewing:1.2569) WL#4259
View as plain text  
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
Thread
bk commit into 6.0 tree (istruewing:1.2569) WL#4259Ingo Struewing12 Mar
  • Re: bk commit into 6.0 tree (istruewing:1.2569) WL#4259Ingo Strüwing12 Mar
  • Re: bk commit into 6.0 tree (istruewing:1.2569) WL#4259Sergei Golubchik12 Mar
    • Re: bk commit into 6.0 tree (istruewing:1.2569) WL#4259Ingo Strüwing12 Mar
      • Re: bk commit into 6.0 tree (istruewing:1.2569) WL#4259Sergei Golubchik17 Mar
        • Re: bk commit into 6.0 tree (istruewing:1.2569) WL#4259Ingo Strüwing17 Mar
          • Re: bk commit into 6.0 tree (istruewing:1.2569) WL#4259Sergei Golubchik17 Mar
            • Re: bk commit into 6.0 tree (istruewing:1.2569) WL#4259Ingo Strüwing18 Mar
  • Re: bk commit into 6.0 tree (istruewing:1.2569) WL#4259Rafal Somla20 Mar
    • Re: bk commit into 6.0 tree (istruewing:1.2569) WL#4259Ingo Strüwing10 Apr
      • Re: bk commit into 6.0 tree (istruewing:1.2569) WL#4259Rafal Somla14 Apr
        • Re: bk commit into 6.0 tree (istruewing:1.2569) WL#4259Ingo Strüwing16 Apr
          • Re: bk commit into 6.0 tree (istruewing:1.2569) WL#4259Rafal Somla16 Apr