[interfacekit] Re: Autolock (fwd)
- From: Erik Jaesler <erik@xxxxxxxxxxxxxx>
- To: interfacekit@xxxxxxxxxxxxx
- Date: Tue, 16 Sep 2003 19:47:00 -0700
I'm with Marcus on this issue. BAutolock has one simple,
clearly-defined purpose in life: scope-based lock management. Let's
keep it that way. I'm all for Waldemar developing a more full-featured
lock management class and placing it in a private header; we can put it
through its paces in internal code to get it ready for *possible*
introduction in the public API.
e
Marcus Overhagen wrote:
------ Forwarded Message: ------
From: "Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx>
Hi,
I just finished the new Autolock.h. I hope it is error-free (did not test it).
:)
If you think it looks okay, I will commit it. Of course, I will try the test
app in our repository before actually committing it. ;)
Any volunteers to write a test app for the new autolock (or extend the
current one)? I have no time for this, sorry (too low priority on my task
list ;).
I'm sorry that I didn't earlier find the time to comment on this issue,
but anyway, it's not too late.
1) BAutolock is a stupid simple class to be used for simple purposes
2) whenever you notice a BAutolock somelock(somevar); at the
beginning of a function, it is save to assume that all data access inside the function is locked
3) you need some special locking inside the Kernel, and want to use BLocker
and a heavily changed BAutolock. I don't like that idea. Kernel code should be
clean and fast. perhaps putting a template for an kernel counterpart for BLocker
inte the util directory would be the way to go (simple benaphore implementation
as templare perhaps)
4) I don't think that extending the functionality of BAutolock in *any* way is a good
idea. It was a simple solution for simple problems, and it should stay that way.
5) I don't conisder it to be good to put confusion on users by adding functions like
SetTo and UnSet into the BAutolock
6) BAutolock has a very simple purpose in life: scope-based lock management.
It should stay that way.
Please refrain from turning BAutoLocker into BAutoLockerAndMore
Don't get me wrong. As you need such functionality, you need to write
something. But please keep LockerHelper.h
regards
Marcus
- Follow-Ups:
- [interfacekit] Re: Autolock (fwd)
- From: Waldemar Kornewald
- References:
- [interfacekit] Re: Autolock (fwd)
- From: Marcus Overhagen
Other related posts:
- » [interfacekit] Autolock (fwd)
- » [interfacekit] Re: Autolock (fwd)
- » [interfacekit] Re: Autolock (fwd)
- » [interfacekit] Re: Autolock (fwd)
- » [interfacekit] Re: Autolock (fwd)
------ Forwarded Message: ------ From: "Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx>
Hi, I just finished the new Autolock.h. I hope it is error-free (did not test it). :) If you think it looks okay, I will commit it. Of course, I will try the test app in our repository before actually committing it. ;) Any volunteers to write a test app for the new autolock (or extend the current one)? I have no time for this, sorry (too low priority on my task list ;).
I'm sorry that I didn't earlier find the time to comment on this issue, but anyway, it's not too late.
1) BAutolock is a stupid simple class to be used for simple purposes
2) whenever you notice a BAutolock somelock(somevar); at the
beginning of a function, it is save to assume that all data access inside the function is locked
3) you need some special locking inside the Kernel, and want to use BLocker
and a heavily changed BAutolock. I don't like that idea. Kernel code should be
clean and fast. perhaps putting a template for an kernel counterpart for BLocker
inte the util directory would be the way to go (simple benaphore implementation
as templare perhaps)
4) I don't think that extending the functionality of BAutolock in *any* way is a good idea. It was a simple solution for simple problems, and it should stay that way.
5) I don't conisder it to be good to put confusion on users by adding functions like SetTo and UnSet into the BAutolock
6) BAutolock has a very simple purpose in life: scope-based lock management.
It should stay that way.
Please refrain from turning BAutoLocker into BAutoLockerAndMore
Don't get me wrong. As you need such functionality, you need to write something. But please keep LockerHelper.h
regards Marcus
- [interfacekit] Re: Autolock (fwd)
- From: Waldemar Kornewald
- [interfacekit] Re: Autolock (fwd)
- From: Marcus Overhagen