The future of C++

[Michael Glassford]

Seriously, I'm against over complexity. The Boost solution is right
something between 90-95% of the time. All I'd ask for is access to
the underlying lock()/unlock() functions on mutex, so I can provide a
custom solution for the few remaining cases.

I'll add it to my list of things to think about. As a quick idea,
would adding protected lock() and unlock() members to the mutex
classes work? (Not public so they can't be called accidentally by
users of the class, not private so you can create a derived mutex
class that works in conjunction with a lock class that you design).

Mike

 

[Matt Austern]

(e-mail address removed) (David Eng) writes:

We are moving to grid computing, yet C++ committee doesn't think it
is important to standardize a thread library.

Please. Did you submit a proposal for a standard threads library?
Did anyone? [hint: the answer is no]

I was under the impression that the Boost threading library was being
discussed. Internally, of course, and only for inclusion in the next
version of the standard.

Someone may be discussing it, but if so only in the hallways between
sessions. And we don't have a proposal. Without a proposal, hallway
discussion is not very meaningful.

We don't have a proposal yet, but my understanding is the same as
James's: that there's discussion going on, with the intention that
a proposal be submitted.

At the moment I believe that Boost threading library is the only
threading library that's likely to be proposed any time soon. So if
anyone here has an alternative threading approach that they prefer,
now's the time to start working on a proposal.

 

[kanze]

Thread-specific data can be used instead of atomic<>-with-membars.

The problem is that at least on some systems, accessing thread specific
data involves acquiring a lock, so you don't gain anything. If an
implementation has a good implementation of thread specific data, of
course, it is an alternative.

Not if it's immutable (or uses atomic<> internally).

But if it's immutable, it is sufficient to ensure that it is created
before starting threading, and you don't need a lock anywhere. (Hmmm.
I suppose if you had a data base in which you could create and destroy
objects, but not modify them, the case might occur.)

 

[kanze]

news:[email protected]...

[snip discussion of std::auto_ptr< boost::lock >(...), etc.]

Seriously, I'm against over complexity. The Boost solution is right
something between 90-95% of the time. All I'd ask for is access to
the underlying lock()/unlock() functions on mutex, so I can provide
a custom solution for the few remaining cases.

I'll add it to my list of things to think about. As a quick idea,
would adding protected lock() and unlock() members to the mutex
classes work? (Not public so they can't be called accidentally by
users of the class, not private so you can create a derived mutex
class that works in conjunction with a lock class that you design).

That sounds like a very good compromize; about the only possible
objection I can see is that it requires an abuse of derivation to use
the special functions.

In one project I worked on in the past, dangerous functions were
qualified with names beginning with "unsafe_"; what about calling them
"unsafe_lock" and "unsafe_unlock"? (OK, it's just an idea. I'm not
fully convinced myself.)

The real problem, I think, is that we are dealing with two levels of
abstraction, one very low level, where you are on your own, and one at a
higher level, which should be used most of the time. Normally, that
would be two, apparently separate classes, and as long as you dealt
strictly at the higher level, you wouldn't need to even be aware of the
lower level. That doesn't quite work here, because even as a client of
the higher level, you have to manage the lifetime and the sharing of the
lower level object; it would be very hard to use Lock if you couldn't
refer to the mutex it should lock on.

So even from a purely abstract design level, I'm not sure what the most
elegant solution would be. What I want is a low level interface that is
not normally available, but that can be made available if I do something
intentional to get to it. And in fact, the only solution I can think of
which meets exactly those requirements is protected. Even if that
wasn't really the original use protected was designed for. Who knows,
maybe we're even creating a new idiom. (It will be an easy idiom to
recognize. How often do you see protected elements in a class with no
virtual functions?)

 

[Pete Becker]

So even from a purely abstract design level, I'm not sure what the most
elegant solution would be. What I want is a low level interface that is
not normally available, but that can be made available if I do something
intentional to get to it.

Sort of like FILE*, from which (with most implementations) you can drop
down to a file descriptor to do lower level reads and writes.

 

[Alexander Terekhov]

But if it's immutable, it is sufficient to ensure that it is created
before starting threading, and you don't need a lock anywhere. ...

But that defeats the purpose (save on memory and/or processor
cycles needed to initialize the thing until the first use...
which may never occur).

regards,
alexander.

 

[kanze]

But that defeats the purpose (save on memory and/or processor cycles
needed to initialize the thing until the first use... which may never
occur).

That's not the purpose; if an object such as std::string is to be
immutable, it must be constructed before the first user thread is
created. The problem is that if you have something like:

static std::string const ref( "someText" ) ;

void
f( std::string const& param )
{
if ( param == ref ) ...
}

you need a lock around the if. Whereas if I do the same thing with char
const[]/char const* and strcmp, I don't. (I am assuming, of course,
that param is only visible in the calling thread, and that f can be
called from more than one thread.)

This seems counter-intuitive; one expects user defined types, especially
such low level user defined types, to behave more or less like built-in
types.

 

[Alexander Terekhov]

That's not the purpose; if an object such as std::string is to be
immutable, it must be constructed before the first user thread is
created.

It must not.

The problem is that if you have something like:

static std::string const ref( "someText" ) ;

void
f( std::string const& param )
{
if ( param == ref ) ...
}

you need a lock around the if.

You need not.

Whereas if I do the same thing with char
const[]/char const* and strcmp, I don't. (I am assuming, of course,
that param is only visible in the calling thread, and that f can be
called from more than one thread.)

You don't need a lock if you do the same thing with std::string.

This seems counter-intuitive; one expects user defined types, especially
such low level user defined types, to behave more or less like built-in
types.

I agree that the following is kinda counter-intuitive.

int thing[123];

int read_global_thing() {
return thing[0]; // non-modifying access
}

vs

std::string thing;

int read_global_thing() {
return thing[0]; // modifying access
}

But the problem doesn't arise if you access it via "const &".

regards,
alexander.