Re: problem Boost libraries
On 1/27/07 4:36 AM, in article
1169893785.703213.264990@s48g2000cws.googlegroups.com, "James Kanze"
<james.kanze@gmail.com> wrote:
Greg Herlihy wrote:
On 1/25/07 1:33 AM, in article
1169686751.981552.142230@s48g2000cws.googlegroups.com,
"n.torrey.pines@gmail.com" <n.torrey.pines@gmail.com> wrote:
1) filesystem:
- Major problems interfacing with the native API on one our targets
(the
Alpha); unmaintainable Boost source, so we couldn't implement any
reasonable workaround
- Uses inherently thread-unsafe function-local statics
At least one C++ compiler, gcc, has a switch for compiling thread-safe local
statics, so workarounds do exist.
G++ does not have a switch for compiling thread-safe local
statics; I'm not even sure what such a switch should do. By
default, recent versions of g++ will handle construction of
local statics in a thread safe manner, on some platforms. You
can turn this feature off, however, and probably should if
you're compiling for a Sparc (since in certain extreme
conditions, the generated code can block due to priority
inversion).
The relevant g++ switch is: -fthreadsafe-statics. This switch guarantees
that a local static object will only ever be initialized once. Otherwise,
two or more threads entering the same routine at around the same time could
both attempt to initialize the same local static object (within that
routine) - each thread unaware that the other thread was doing the same.
The important point is that this switch exists - not the value of its
default setting. As it happens g++ enables the threadsafe static switch by
default. But the fact that the programmer does have to enable this switch
explicitly only reinforces my original point that - contrary to the claim
being made - local static objects are not necessarily "inherently" unsafe in
C++. In fact, in the case of at least one C++ compiler, the opposite holds
true: static local objects are safe in a multithreaded environment - and are
so by default.
C++ itself is not "thread-aware" so any
solution would have to depend on the compiler.
Boost is thread-aware, and any Boost code could use
boost::threads. The question isn't there, however. The
question is rather: what guarantees does the compontent make
with regards to threads, and does it meet them. I wouldn't like
a component that documented that you cannot use multiple
instances of a class in different threads without external
synchronization, but if it documented exactly when you needed
the synchronization, it's thread-safe.
The "race conditions" are not caused by other threads within the same
program - but by other processes on the same (or even on another) machine.
The file system is a globally-shared resource - so it is not possible for a
filesystem library to eliminate race conditions on its own. If race
conditions are to be eliminated, the program will have to do so itself -
presumably by taking whatever steps are necessary (assuming such steps
exist) to prevent other processes from performing file system operations
that would conflict with the program's own.
3) serialization
- A header race; doesn't tolerate including <boost/shared_ptr.hpp>
before
<boost/serialization/shared_ptr.hpp>
Why would the fact that one header needs to be included before another be a
"race" condition? Do you expect to be able to include headers in any order?
I certainly do. It's part of good software engineering.
Header file dependencies are an inescapable fact of programmin in C++ . For
example, assume that a C++ program has a header file, "program.h", that
declares a class with a std::string data member. Therefore, in order to
include "program.h" the <string> header file will have to included as well.
Now, if C++ really allowed header files to be included "in any order" then
it would not matter whether <string> was included before or after
"program.h' just as long as <string> was sure to be included.
In reality, C++ is quite inflexible when it comes to the order of included
header files: in this case, <string> must be included before "program.h" -
otherwise including "program.h" will not compile. Of course, in this case,
it makes sense for "program.h" to include <string> itself rather than rely
on the program to do so, but however <string> is included - does nothing to
eliminate "program.h"'s dependency on <string>.
The requirements for using the boost serialization library are no different.
In this case, the program instantiates a serialization class template with
the parameterized type of the object to be serialized. Therefore the
definition of the parameterized type must be visible at the point at which
the serialization template class is instantiated. To take an example: a
program that wishes to serialize an object of class A, must first include
A.h before it includes the serialization header file that contains the class
template definition.
Now the only between the two examples is that - unlike "program.h" the
serialization library header file cannot predict beforehand what type the
user intends to serialize - so cannot know which header file it must
include as a convenience to handle the dependency - the program simply has
to include the appropriate header file itself. But in all other aspects the
two examples are identical - and both are constrained by the rules of the
C++ language and not by any "design defect" of their own making.
- Yet another header race involving headers in both boost/archive and
boost/serialization; details on request
I think it is reasonable to expect that a serialization library would have
very specific dependencies (probably more than most libraries) owing to the
nature of its operation. But dependencies by themselves are not some kind of
defect. After all, how would one go about implementing a serialization
library completely free of dependencies?
Dependencies in the order of inclusion of header files are a
serious defect. Other dependencies may be unavoidable: order of
inclusion of libraries, for example.
The C++ Standard has no notion of an include order for libraries. In
contrast, a C++ program that includes header files must specify the order in
which they are to be included; and the program must observe strict rules
governing how various declarations and definitions have to be sequenced.
Granted it would be nice if C++ were more tolerant about the order in which
a source file brought in a set of header files. But unless and until the C++
language is amended to allow such flexibility, the order that header files
are included by a C++ program will continue to be significant - it's simply
a fact of programming life. And any expectation to the contrary is simply
not realistic.
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]