Jason,
thanks for comment. I must to recheck code patch again, because maybe
you are really right.
Honza
jason napsal(a):
> Hi Jan,
> I think we need a memory barrier here between sync_in_process = 0 and
> totempg_trans_ack() or have to introduce a lock to protect them both.
> Otherwise, on some memory reordering multicore architectures, this code
> swaping seems meanless.
> 在 2013-3-21 下午5:11，"Jan Friesse" <jfriesse@xxxxxxxxxx>写道：
>
>> If IPC thread is waiting for allow_send and sync_in_process is changed
>> before trans_ack, message may be copied to incorrect queue. Solution is
>> to swap sync_in_process and trans_ack.
>>
>> Signed-off-by: Jan Friesse <jfriesse@xxxxxxxxxx>
>> ---
>> exec/main.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/exec/main.c b/exec/main.c
>> index 6c8ea35..45abc9f 100644
>> --- a/exec/main.c
>> +++ b/exec/main.c
>> @@ -272,11 +272,11 @@ static void corosync_sync_completed (void)
>> {
>> log_printf (LOGSYS_LEVEL_NOTICE,
>> "Completed service synchronization, ready to provide
>> service.\n");
>> - sync_in_process = 0;
>> /*
>> * Inform totem to start using new message queue again
>> */
>> totempg_trans_ack();
>> + sync_in_process = 0;
>> }
>>
>> static int corosync_sync_callbacks_retrieve (int sync_id,
>> --
>> 1.7.1
>>
>> _______________________________________________
>> discuss mailing list
>> discuss@xxxxxxxxxxxx
>> http://lists.corosync.org/mailman/listinfo/discuss
>>
>
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
