Hi You could *still* get interrupted between the if and the increment.
/AndersBj -----Original Message----- From: Neelakanta Reddy [mailto:[email protected]] Sent: den 13 augusti 2015 08:00 To: Zoran Milinkovic; Anders Björnerstedt; [email protected] Cc: [email protected] Subject: Re: [PATCH 1 of 1] imm:Decrement sqliteTransLock when BEGIN EXCLUSIVE TRANSACTION fails [#1426] Hi zoran, comments below. /Neel. On Wednesday 12 August 2015 06:20 PM, Zoran Milinkovic wrote: > Hi Neelakanta, > > What will happen if there is a context-switch between thread1 and thread2 > just after "while(sqliteTransLock) {" when sqliteTransLock == 0 ? > Then both thread1 and thread2 will pass 'while' loop and both threads will > increase sqliteTransLock. In this case, both thread will increment. The result will be one thread will abort the transaction and other thread will assert when pbeClosePrepareTrans is called. > The likelihood that this happen is very very low, but I think that this case > should also be covered. yes, the likelihood is very low, but the fix could be check sqliteTransLock before incrementing. if(!sqliteTransLock) ++sqliteTransLock; /* Lock is set. */ > Best regards, > Zoran > > -----Original Message----- > From: Neelakanta Reddy [mailto:[email protected]] > Sent: Wednesday, August 12, 2015 8:48 AM > To: Zoran Milinkovic; Anders Björnerstedt; [email protected] > Cc: [email protected] > Subject: Re: [PATCH 1 of 1] imm:Decrement sqliteTransLock when BEGIN > EXCLUSIVE TRANSACTION fails [#1426] > > Hi zoran, > > In the few line above there is check to verify sqliteTransLock in " > while(sqliteTransLock) {" . > > Multiple threads are present only for 2PBE case. In the 2PBE case if a > thread1 is waiting for lock and got the lock released, then sqliteTransLock > will be incremented. If in this time a context-switch happens then the > thread2 will be spinning in sqliteTransLock. > > Decrementing of sqliteTransLock may not be required. > > /Neel. > > > On Tuesday 11 August 2015 06:34 PM, Zoran Milinkovic wrote: >> Hi Neelakanta, >> >> Shouldn't sqliteTransLock be also decremented few lines above in " >> if(sqliteTransLock != 1) {" statement ? >> >> Thanks, >> Zoran >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] >> Sent: Thursday, July 30, 2015 3:47 PM >> To: Anders Björnerstedt; Zoran Milinkovic; [email protected] >> Cc: [email protected] >> Subject: [PATCH 1 of 1] imm:Decrement sqliteTransLock when BEGIN >> EXCLUSIVE TRANSACTION fails [#1426] >> >> osaf/libs/common/immsv/immpbe_dump.cc | 1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> >> There is a chance that NFS/shared-storage may re-attach after few >> seconds, and transaction is not yet started, so decrement the >> sqliteTransLock in pbeBeginTrans which releases the lock >> >> diff --git a/osaf/libs/common/immsv/immpbe_dump.cc >> b/osaf/libs/common/immsv/immpbe_dump.cc >> --- a/osaf/libs/common/immsv/immpbe_dump.cc >> +++ b/osaf/libs/common/immsv/immpbe_dump.cc >> @@ -2909,6 +2909,7 @@ SaAisErrorT pbeBeginTrans(void* db_handl >> LOG_ER("SQL statement ('BEGIN EXCLUSIVE TRANSACTION') failed >> because:\n %s", >> execErr); >> sqlite3_free(execErr); >> + --sqliteTransLock; >> return SA_AIS_ERR_FAILED_OPERATION; >> } >> return SA_AIS_OK; ------------------------------------------------------------------------------ _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
