Sergei Golubchik writes:
>> So now the algorithm is something like this:
> Where in this algorithm you call ht->commit_ordered() ?
Oops, I forgot, sorry!
It should be at the start of "for thd2 in " (before the wakeup).
>> thd->ready= false
>> lock(LOCK_prepare_ordered)
>> old_queu
Hi, Kristian!
On Sep 06, Kristian Nielsen wrote:
> However, as I revisited the algorithm, it occured to me that it is in
> any case better to wake up threads individually as soon as
> commit_ordered() has finished. This way, the first threads in the
> queue are free to continue doing useful work w
Sergei Golubchik writes:
> Hi, Kristian!
> Hot and cool, yes, I've used (and coded) them myself :)
> But I only use them where I believe they actually improve concurrency,
> and I think this one is not the case.
Very true.
So let us forget about the lock-free stuff. I'll remove the atomics and
Hi, Kristian!
On Sep 03, Kristian Nielsen wrote:
>
> >> - If we have consistent commit order, we can think about
> >> optimising commit to need only one fsync (for binlog); lost
> >> commits in storage engines can then be recovered from the binlog
> >> at crash recovery by re-playing against
Sergei Golubchik writes:
> Hi, Kristian!
>
> Let's start from the WL description:
Thanks for your detailed comments!
>> While currently there is no server guarantee to get same commit order
>> in engines an binlog (except for the InnoDB prepare_commit_mutex
>> hack), there are several reasons w
Hi, Kristian!
Let's start from the WL description:
> While currently there is no server guarantee to get same commit order
> in engines an binlog (except for the InnoDB prepare_commit_mutex
> hack), there are several reasons why this could be desirable:
...
> - Other backup methods could have si
6 matches
Mail list logo
