[interfacekit] Re: Fwd: BAutolock

"Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx> wrote:
> > > > I think the name of this method is misleading, it should just 
> > > > be
> > > > Lock() IMO.
> > > Okay. I hope that the devs do not think a second Lock() will lock 
> > > the
> > > BLocker twice.
> > Will Unlock() unlock a BLocker twice?
> > It's all a matter of documentation - and I think a Relock() does 
> > even
> > more appears to lock twice (cause it would seem to relock the 
> > locker)
> > :)
> Well, that is the reason why I wanted to call Unlock() UnlockNow(), 
> but you
> would not have liked that name, either. ;)

Exactly! :-)

> > > First of all: what does Keep() do?
> > It would prevent the BLocker from being unlocked upon destruction 
> > of
> > the BAutolock. I just mentioned it because that's what I am 
> > personally
> > using in similar cases.
> Okay, then it is the same as SetLockStatus(false).

In that case, I would prefer a Keep() method over SetLockStatus() - 
it's simply clearer what it does.

> > We could even have it like this:
> > SetTo(BLocker &locker, bool isAlreadyLocked = false);
> Now I understand!
> With SetTo() you can change the current locker object!

Exactly.

> > BAutolocker locker(lockA);
> >
> > if (...) {
> > locker.Unset();
> > locker.SetTo(lockB);
> > }
> In real world issues you would not need the Unset(), right?
> But in those situations the locker will be unlocked before setting 
> another
> target.

Yes, SetTo() would call Unset() itself - but if we have this "unlock" 
parameter, you could set it to false here explicetly.

> > Why should it return another value?
> Because you thought a bool is sufficient for your Benaphore class. 
> But
> when BAutolock compares the return value of Lock() with B_NO_ERROR 
> its return value will be true for Benaphore's return value of false.
> We could just assume that Lock() always returns the return value of
> acquire_sem().

Yes, Lock() should generally return a status_t. But there is a 
difference between a kernel acquire_sem() and a userland acquire_sem() 
- the latter is interruptible, the former not. That's why you can 
safely do:

acquire_sem(someLock);
...
release_sem(someLock);

Without checking for the return argument of acquire_sem() safely in the 
kernel, but not in userland. The only reason why the above call would 
fail in the kernel is when someLock doesn't exist anymore - only if 
that would be possible, you should better check the return value.

Adios...
   Axel.

Other related posts: