Browse interfacekit: This Month's Archive • Main Archive Page • Related posts • Previous by Date • Next by Date
[interfacekit] Re: Fwd: BAutolock

From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
To: "OpenBeOS Interface Kit" <interfacekit@xxxxxxxxxxxxx>
Date: Thu, 11 Sep 2003 17:08:37 +0200 CEST
And again:

From: "Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx>
> "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> wrote:
> > This is a forward from Waldemar - Erik, could you please open up 
> > this
> > list? :-)

Yes, please. :)

> See? Now I even have to answer to my own mails :)

:)

> Waldemar wrote:
> > > Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > > > On 2003-09-11 at 07:24:38 [+0200], Waldemar Kornewald wrote:
> > > [...]
> > > > > bool Relock()
> > > > > This locks the BLocker/BLooper object if it is not already
> > > > > locked
> > > > > by this
> > > > > object. This method is called by the constructor(s).
> > > 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. ;)

> > > > > void SetLockStatus(bool lockStatus)
> > > But this one is pretty much useless in my opinion.
> > > I would rather have Set() and Unset() pairs (I am frequently 
> > > using
> > > a
> > > method Keep() in similar things, though).
> > > Set() could have a parameter that specifies if the BLocker is
> > > already
> > > locked or not, Unset() would not unlock it on destruction. That
> > > would
> > > allow it to use in almost all locking cases.
> > 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).

> > I think SetLockStatus() does the same as your Set().
> > Set(true) is equivalent to SetLockStatus(true), but I prefer my
> > naming.
> > :)
>
> No, it would come along with an empty constructor, and could be used
> like this, btw, it should even be called SetTo():
>
[*some code*]
>
> 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!

> > Why do we need Unset()? Set(false) (or SetLockStatus(false)) 
> > already
> > says that it does not need to be unlocked, does it?
>
> It does a bit more, you could do things like:
>
> 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.

> Although it looks like it's meaning is not even as clear as I thought
> it would be, because you don't know if Unset() unlocks the BLocker or
> not.
> I would think Unset() defaults to unlock the BLocker, maybe it could
> have a default parameter like this:
> Unset(bool unlock = true);
>
> Then it could be the same as my Keep() when using it like this:
> Unset(false);

Okay, I see the whole picture now.

> > What about replacing it with a more general template? On the other
> > hand, who
> > says Lock() returns status_t (or bool) in all classes? Your own
> > Benaphore
> > class might return another value.
>
> 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().

Waldemar
[interfacekit] Re: Fwd: BAutolock

Other related posts:
