Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-03-26 19:05:09

--- In boost_at_y..., Jens Maurer <Jens.Maurer_at_g...> wrote:
> williamkempf_at_h... wrote:
> > [Jens Maurer wrote:]

> [ Interfaces vs. performance]
> > Unless you think the interface prevents creating
> > efficient implementations
> So I believe.

That wasn't clear in your first post. Care to elaborate?

> > > Also note that the pimpl-wrapping in boost::fast_mutex costs
> > > 10% performance.
> >
> > I don't see this evidenced in your timings above. How did you
> > this out?
> Your fast_mutex takes 0.25 usec, even the slowest native mutex
> takes only 0.22 usec. That's about 10% (or even more) of a
> to me.

There's no evidence that pimpl causes this, however. There are other
factors involved. The only real test would be to run timings for
both pimpl and non-pimpl.
> > You must not be looking at the latest upload, which makes me
> > your timings above. The implementation changed drastically for
> > pthreads and so they may (likely will) run much faster if you
> > were using an older implementation. As for bool conversions,
> > long since been replaced by void* conversions.
> I'm confused. I've looked at
> dated 2001-03-22, size 62080 bytes, which seems to be the latest
> as of this writing. boost/thread/xlock.hpp contains three operator
> functions.

Ok, let me check this out later tonight just to be sure of what's
going on. The bool conversions were changed to void* conversions at
least to uploads ago, so I'm not sure what's going on. I'll get back
to you on this one.
> > > - The timedlock interface (milliseconds) should be changed to
> > > the equivalent of POSIX timespec, i.e. seconds and nanoseconds
> > > be future-safe.
> >
> > A) I very much dislike using a "time out at a specified time"
> > implementation preferring to "time out after a specified
> Sorry, I should have been more descriptive: I mean the "time out
> a specified duration" semantics are what they should be. However,
> I advocate using seconds and nanoseconds to specify the duration.
> Since the largest portable datatype is long (32 bits min.
> we need to split the duration into a "long" for the nanosecond
> (fractional) part of the duration and another "long" for the seconds
> part. I mentioned "timespec" for exposition of the kind of
> description for the timeout.

In C++ I wouldn't pass a structure for this. I'd pass two longs.
That aside, this is not totally unreasonable, excepting the next
> > C) It might be possible to define the waits in terms of seconds
> > nanoseconds, the basic options available with timespec, but not
> > platforms support this fine a grain of time duration.
> > are more likely to be implementable on multiple platforms. This
> > the reasoning chosen at the time these interfaces were designed,
> > I'm not locked into this.
> My reasoning is that the interface should not preclude more
> precise timeouts. It should be implementation-defined what the
> internal resolution of timeouts is (i.e. every platforms defines
> the resolution). We can have a general "at least microseconds
> resolution is available everywhere" clause, but this is incorrect
> Linux/x86 at least which only has 100 Hz scheduling frequency.

Reasonable, and I'll definately consider this change. What I'm not
sure about is when such precision would ever be useful, but that's
not a good argument against.
> > > - atomic_t should say that value_type must be at least "int".
> > > Otherwise, it's of not much use in the real world.
> >
> > I'm not sure I follow you here. Care to explain?
> According to my reading, atomic_t's value_type is
> "implementation defined", with no restriction on what the type may
> be.

It needs to be integral. I can make that requirement better stated.

> So it could be a "bool", seriously limiting the portable
> use of atomic_t, because the portable assumptions I can make
> on atomic_t are rather limited. If you say it's at least an "int" ,
> I can be sure it's 15 bits at least (guaranteed by the C++

I'm not sure that that's appropriate. That's why I asked you to
explain. It might be that an implementation needs to use short in
order to get hardware supported atomic operations (yes, I know this
is extremely unlikely since int's are supposed to be the preferred
platforms integer size). In reality I'd expect all implementations
to use int, but should the documentation be so rigid as to preclude
short from use for instance?
> > > - How do I put a variable number of mutexes in a dynamic data
> > > structure? Say, I'd like to implement the "dining philosophers"
> > > problem with a runtime configurable number of philosophers?
> >
> > I don't see the problem here either.
> I don't remember all the details of the dining philosophers'
> but here's my current interpretation: There are n philosophers
> a round table, with n forks between them. There's a plate with
> an unlimited amount of spaghetti in front of each philosopher,
> but any philosopher needs the fork to its right *and* the one
> to its left to start eating. A philosopher can decide to stop
> eating (and return the forks) for a while. Everyone should have a
> chance to eat once in a while. Assume there's no global
> coordination (e.g. numbering the philosophers and having the
> even numbered ones eat first and then the odd numbered ones and
> so on).

I'm familiar with dining philosophers. In fact, starve_phil is a
variation on this classic problem. What I didn't understand was what
you thought was difficult to do with Boost.Threads while solving this
> For a trivial (possibly deadlock-prone) solution, I'd like to have
> a std::vector<mutex>, one mutex for each fork (a fork is a shared
> resource and thus needs to be protected). However, a mutex is
> noncopyable and thus not usable in a standard container.

So, you're problem has nothing to do with "How do I put a variable
number of mutexes in a dynamic data structure" (at least as I read
that) but with how you can store these types in a standard
container. The solution is no different than how you'd do it with
any noncopyable type... allocate it on the heap, probably controlled
by a wrapper such as shared_ptr. I'm not sure that something like
this deserves explicit documentation, though I can certainly do so.

> Here's the conceptual question: How can I have a runtime-
> amount of mutexes (here: representing forks)? (No, I don't want
> to allocate these with "new" manually. Too tedious and error-

Neither tedious nor error prone when properly wrapped (which may not
mean wrapped with shared_ptr).

It seems to me that what you're really getting at is that you'd
prefer the types to be copyable. This opens up a huge can of worms.
It was considered and rejected.
> > The only define really used outside of compiling Boost.Threads
for a
> > given platform is BOOST_HAS_THREADS. I imagine the other defines
> > could be specified by the build process instead of being placed
in a
> > header at all.
> Ok, so we don't expand config.hpp, but have a threads-private header
> for the threads configuration, while we're waiting for the boost
> system to happen. (No need to depend on vaporware).

Or the needed defines are just part of the multitude of
makefiles/project files supplied for building. This would probably
be easier than the header approach, whether the header is config.hpp
or threads/config.hpp.
> > I don't think we should use additional headers. Either specify
> > at build time, or leave them in config.hpp. Defining a new header
> > for this is only going to complicate things for users.
> Why? The user (of the boost library) never has anything to do with
> these defines (and, in an ideal world, should have no business
> with defines in config.hpp).

I'm looking at it from the implementors stand point, not the final
end users. Sorry, I didn't state that very well. Any of the three
solutions will be transparent (mostly, any way) for the end users.
> So having a new header will just clearly separate compiler/library
> issues from OS/hardware things. For example, implementing atomic_t
> on Linux will need to be done from scratch (as far as I can see
> at the moment), so it's very much CPU dependent.

That's why I think it's better to do it in the build system. Hacking
any header for this level of information is going to be very
difficult to do given the little bit of info available to the

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at