> According to Alexander Viro:
> > On Sat, 16 Jan 1999, Chip Salzenberg wrote:
> > > Stroupstrup's design rule: "Constructors acquite resources;
> > > destructors release them."
> >
> > So, you are going to allocate an object in stack for each
> > semaphore you are holding?
>
> Yup.
>
> > shitload of overhead even if we'll do it in assembler
>
> I doubt that very strongly. Consider that the object need not be
> polymorphic; all it needs is a pointer member. And if you use a
> template class, you don't even need the pointer, so it'll be 100% as
> efficient as the C version (except one byte for the object itself
> (zero-length objects are not allowed (yet))).
>
> Given:
>
> template <semaphore_t *SEM>
> class hold {
> public:
> hold() { down(SEM); }
> ~hold() { up(SEM); }
> };
>
> The code would look like:
>
> void random_function()
> {
> hold<&one_semaphore> hold1;
> hold<&other_semaphore> hold2;
> // ...
> }
And if you'll call something that will throw an exception here it will
compile to? BTW, there are many places where you
* release the lock on different pathes.
* don't want to hold it too long.
* release it from another function, called by you.
* have to release a spinlock before the blocking operation.
* have scopes incompatible with syntax ones, e.g
if (!wee) unlock(&hop);
lock(&foo);
while(bar()) {
if (baz()<0) {
barf();
if (wee) unlock(&hop);
unlock(&foo);
return;
}
unlock(&foo);
quux();
lock(&foo);
fred();
}
barf();
unlock(&foo);
Again, C++ issues aside, you can't do it by magic. You have to store the
information re: what is hold.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/