On Mon, Jan 14, 2013 at 12:04 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Sun, Jan 13, 2013 at 11:44 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Sun, Jan 13, 2013 at 11:15 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
I believed it also but the mutex shouldn't be locked while doing notifications, only when you change the condition and when you wait for the condition to be notified.
Looking at the code now it seems there is a potential race condition. The commit or rollback can set the flag and issue the broadcast just before the enter method acquires the lock and blocks in the cv.
I suppose there should be a second check for the flag value under the lock in the enter_once_region method. The locks in commit and rollback functions can be removed altogether then.
I attached the updated once.cpp.
No, that code is not correct either. The lock in commit and rollback functions *is* needed and it *must* cover both the store and broadcast exactly to prevent missed notifications. Otherwise thread A can check for the flag value but not yet enter pthread_cond_wait and thread B can store the new flag value and issue pthread_cond_broadcast. I attached the corrected code. Apologies for the confusion.