> ----------
From:
xxxxx@compuware.com[SMTP:xxxxx@compuware.com]
Reply To: xxxxx@lists.osr.com
Sent: Friday, September 26, 2003 4:28 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: Problem using queued spinlocks on single cpu
comp uter
- I really dislike splitting spinlock usage into two objects, I think it
defeats the purpose of C++ encapsulation.
Maybe. But OS expects one KLOCK_QUEUE_HANDLE per acquisition and you have to
design spinlock class this way. The easy way is to use two classes. The hard
way is to use one object and allocate one KLOCK_QUEUE_HANDLE per processor
and for every acquire decide which one to use. Complicated, error prone and
no real advantage.
I can see it’s convenient, you
create the object on the stack and when you collapse the frame, presto,
it’s
gone - but that comes at the price of encapsulation, and makes me feel
like
I’m not programming in object-oriented style any longer !
A bit dogmatic view. With C++ exceptions and templates some things changed.
As for exception
safety, a spinlock should be the lowest level in the hierarchy, so, it
shouldn’t have to concern itself with that kind of thing: you either spin
or
you don’t. If processor P1 is spinning, nothing that happens to P2 should
matter as far as P1 goes, unless of course the OS decides to take a
catastrophic exit, but then, that’s not a driver writer issue.
No, you don’t understand how it was mentioned. Example should show it:
SpinLock.Lock();
if (something_went_wrong) {
throw Error;
}
SpinLock.Unlock();
Apparently, if something went wrong, spinlock isn’t unlocked. To solve it,
Error has to be catched and lock unlocked. Local acquisitor object is
unlocked automatically. The result is shorter and cleaner code.
Above can be fixed other way, of course. Below can’t:
SpinLock.Lock();
a = b;
SpinLock.Unlock();
Quite innocent, isn’t it? What if operator ‘=’ throws an exception? With
exception unsafe class as SpinLock is you always have to enclose protected
sections into try/catch block. With exception safe class as lock acquisitor
is you don’t have to. The point is without exception safe classes you always
have to take care about exceptions and sooner or later you make an error.
For example, if above code if used for integers originally and later moved
to a template and used for classes whose operators can throw exceptions.
That’s why classes as lock acquisitor are widely used for synchronization
objects as mutexes, evens and critical sections. Other possibility is to not
use C++ exceptions at all.
(I intentionally ignore function exception specification i.e. throw() which
can help if used correctly. AFAIK, VC compiler also ignored it in past
years; I’m not sure about latest versions)
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]