[interfacekit] Re: Autolock (fwd)

I agree with Marcus' sentiments here also.  I am not sure adding 
complexity to BAutolock is the right thing to do.  At most, I think a 
"Unlock()" method to release the lock before destruction is probably 
useful.  Perhaps I am not thinking about some important cases where 
this extra functionality would be useful.  Are there actual code 
examples people can point to in the OBOS source tree or elsewhere which 
would be improved by these new methods?  I think that would help me 
understand why we want to add so much to BAutolock.

That said, if the decision is to go with the new implementation, I will 
look into some testcases and update the use case docs.  Just give me 
the word to go ahead.

> 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

--
Jeremy Rand
jrand@xxxxxxxx

Other related posts: