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" <[email protected]>写道： > >> 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 <[email protected]> >> --- >> 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 >> [email protected] >> http://lists.corosync.org/mailman/listinfo/discuss >> > _______________________________________________ discuss mailing list [email protected] http://lists.corosync.org/mailman/listinfo/discuss
