Hi!
Alfranio Correia wrote:
> Hi Jasonh,
>
> Thank you for the reply.
> See some comments in-line.
>
> Cheers.
>
> He Zhenxing wrote:
>> Hi Alfranio,
>>
>> Thank you for the review!
>>
>> Alfranio Correia wrote:
>>
>>
>>>>
>>>>
>>> I haven't followed the comment.
>>> Can you elaborate more on that?
>>>
>> I had to say I'm not quite sure about the comment either, I guess it
>> means that the value for system variables will be initialized after
>> set_options(), I'll check more on that.
>>
>>
> ok.
>>>> +
>>>> + /* Mutex initialization can only be done after MY_INIT(). */
>>>> + pthread_mutexattr_t mutexattr;
>>>> + pthread_mutexattr_init(&mutexattr);
>>>> + pthread_mutexattr_settype(&mutexattr,
>>>> + PTHREAD_MUTEX_FAST_NP);
>>>> +// pthread_mutex_init(&LOCK_binlog_, MY_MUTEX_INIT_FAST);
>>>> + pthread_mutex_init(&LOCK_binlog_, &mutexattr);
>>>>
>>>>
>
>>>> +{
>>>> + const char *kWho = "ReplSemiSyncMaster::reportReplyBinlog";
>>>> + int cmp;
>>>> + bool can_release_threads = false;
>>>> + bool need_copy_send_pos = true;
>>>>
>>>>
>>> Why are you checking the variable before acquiring a lock?
>>>
>> This so called Double-check-locking, can avoid to acquire the lock if
>> the value is false
>>
>> http://en.wikipedia.org/wiki/Double_checked_locking_pattern
>>
>
> Ok. I did not know this pattern. However, I've checked the
> Schmidt, D et al. Pattern-Oriented Software Architecture Vol 2, 2000
> pp353-363
> and it seems that there are problems with some platforms and compiler
> optimizations.
>
> 1 - First make the variable volatile to avoid caching it in a register.
> 2 - Check with Mats if MySQL runs on Compaq Alpha or Intel Itanium. In
> such platforms,
> if the cpu cache is not properly flushed if shared data is not accessed
> without locks.
I am pretty sure that we support Intel Itanium. Regardless, I think that we have
to do that. Alpha is less of a problem, since it is very rare.
However, the double-checked locking pattern does not work in C++ because the
compiler is allowed to do optimizations assuming that only a single thread is
executing. This means that the construction of an object is generally not
linearizable, meaning that is has a "initialization period" and does not appear
as if it is atomic. The code you have is different, so I take the canonical example:
extern Object *ptr;
...
if (ptr == 0) {
lock();
if (ptr == 0) {
ptr = new Object;
...
}
}
What normally happens in the compiler is that memory is allocated and assigned
to the variable in question, after which the constructor is called. This means
that another thread that starts reading the same pointer, may discover a pointer
that is initialized and will therefore read uninitialized memory. In other
words, the compiler can compile the code above behaves as if it was written the
following way:
extern Object *ptr;
...
if (ptr == 0) {
lock();
if (ptr == 0) {
ptr = ::operator new(sizeof(Object));
new (ptr) Object;
...
}
}
Note that this is not a rare case, but quite commonly used by compilers. In
general, I would not trust double-checked locking as a technique without special
support from the compiler (e.g., by using GCC:s intrinsic function
__compare_and_swap(), and even then one have to be careful and know what a
compiler can do with the code).
I think this will change with C++0x, but I haven't considered this case with the
new semantics yet...
/Matz
>
>
>>>>
>>>>
>>> Can you explain the variable below?
>>>
>>>> + unsigned long wait_backtraverse_; /* wait position
> back traverses */
>>>>
>> usually the position waiting for should increase, this variable will
>> record the times that the position to waiting for reply decreases,that
>> is the later written binlog has a smaller position.
>>
>> I have not check if this can happen, probably can be caused by InnoDB
>> engine.
>>
>>
> Maybe due to the internal 2PC, when the XID does not get into the binary
> log.
> Try to create a test case for this, maybe using the following fault
> injection
> string "crash_before_writing_xid" (check log.cc:6340).
>
--
Mats Kindahl
Senior Software Engineer
Database Technology Group
Sun Microsystems
