Hi AndersBj,
yes, the interruption may happen between if and increment.
As suggested by zoran decrement sqliteTransLock in "if(sqliteTransLock
!= 1) { /* i.e. not 2 or 3 */".
/Neel.
On Thursday 13 August 2015 11:54 AM, Anders Björnerstedt wrote:
> 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
