>
>
>On Sat, 16 Jan 1999, Chip Salzenberg wrote:
>
>> 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
Which is one of the reasons I would not support allowing the use of C++
exceptions in the kernel, even though other parts of C++ could be useful.
> * 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/