Re: Critical Section
On Nov 26, 5:39 am, Joseph M. Newcomer <newco...@flounder.com> wrote:
{
CSingleLock l(&syncObject, TRUE);
container1.push_back(data1);
ScopeGuard g1 = MakeObjGuard(container1, &c1type::pop_back);
container2.push_back(data2);
ScopeGuard g2 = MakeObjGuard(container2, &c2type::pop_back);
container3.push_back(data3);
// All fine, keep all data in
g2.Dismiss();
g1.Dismiss();
}
*****
But here, you are assuming that the state of the object is guaranteed to =
be correct if
push_back throws an exception. But what if the exception is thrown par=
tway through the
modification of a structure? push_back is not an atomic operation, and=
there is no
guarantee that if an exception is thrown in the middle of push_back that =
the data
structure is intact
I presumed that push_back is something from STL (e.g. a vector). While
there's no exception guarantee spec for push_back in the C++ standard,
I know that it does have strong exception guarantee in any
implementation used by MS that I've seen. So the "atomic" guarantee
exists on the STL level. On the level of data, it is of course,
programmer's job. For example, copy constructor for data1/2/3, that
will be invoked when adding it to the vector, should not leave poor
global state (it's seldom the case that it will even try to touch it),
and of course, should have strong exception guarantee, too.
generally indicates the state of the object is undefined). Overall, th=
e requirement of a
"strong" guarantee of correctness is hard to achieve, and I'm not sure th=
e above code
really accomplishes it.
Sure, it's always possible that there is a bug somewhere. But when
thinking in terms of exception safety guarantees, it's not that hard
to get the logic right. In the example above, issues are as follows:
* code inside lock must have strong guarantee (pretty obvious
requirement)
* adding an element to a container is a throwing operation, but
generally an atomic one as far as the container is concerned (has a
strong guarantee)
* removing an element must be a no-throw operation, and it generally
is (for example, no implementation of a std::vector::pop_back I have
seen will not try to shrink, even if there's a lot of free space left
now, exactly for this reason: if it tries to shrink, it has to
allocate new storage and copy what's left; all this is a throwing
operation, so none of that will happen anytime soon)
* copying an element has strong guarantee, not hard, either; only
issue is modification of the state outside the object.
To me, that's not hard.
Supposed, for example, that my requirement was that if any
exception is thrown, NO elements have been added to data1, data2 or data3=
..
Yes, my snippet above presumes this very requirement.
Using lock/unlock guarantees that data is locked/unlocked without a
guarantee that data integrity is preserved just the same.
****
No, the explicit lock/unlock does have the side effect that if an excepti=
on is thrown, the
lock is NOT unlocked, leaving the corrupted data inaccessible/
You are mistaken, and I already pointed out your mistake: using e.g.
critical section of windows (a recursive mutex, mind), there is
nothing stopping the thread that experienced the exception to go back
to the same data and access "corrupted" data. Your idea only works if,
upon exception, thread terminates without touching said data ever
again.
In the example above, if you use explicit lock/unlock and no scope
guard (or try/catch), and container2.push_back fails, you have utterly
horrible bug: the lock is there forever for any thread except the one
where container2.push_back failed, data is not consistent even in that
thread, and you can touch it later. In other words, CSingleLock or
explicit lock/unlock, you, the programmer, have to insure data
integrity. Both approaches are a 100% orthogonal to shared data
integrity.
****
But having the lock there forever is GOOD! It means that potentially c=
orrupted data is
inaccessible! RAII guarantees that potentially corrupted data becomes =
accessible.
****
No, it's not RAII that guarantees this, it's the programmer who didn't
think his exception guarantees for the code inside the lock.
I don't believe that the release of the scope guard can be guaranteed to =
not throw
exceptions; in fact, this contradicts years of experience.
Why, of course that there is no such guarantee, isn't that obvious? It
is the __programmer's job__ to make sure of that. Just like a
destructor must be a no-throw operation, or just like the
"finally"block in Java must be a no-throw operation, or just like an
implementation of IDisposable::Dispose of .NET must be a no-throw
operation. It's 100% same thing!
Imagine e.g. in java: try { work() } finally { rollback() }
If rollback is e.g. void rollback() { cleanupThatCanThrow();
somethingElse(); }
and cleanupThatCanThrow indeed throws, BOOM! goes consistency (mind,
irregardless of any threading concerns; RAII and threading are 100%
orthogonal). There's nothing in Java language that can prevent these
kinds of bugs. One needs much, much stronger exception design
capabilities than Java's checked exceptions for the language to
actually be able to help with these issues.
Goran.