Boost logo

Boost :

From: Ion Gaztañaga (ion_g_m_at_[hidden])
Date: 2005-08-15 12:48:50

> 1) Boost Thread library work seems to have slowed considerably and yet now
> more than ever this is one area where C++ is sadly lacking. Recent

It's a shame since there were some comments about reworking some
components like rw_locks. There was also a discussion about the interface.

> commentaries such as Kevlin's on this list have not necessarily flattered
> the Boost thread design, but do we have a champion(s) who are/could help to
> address this, or are alternative efforts happening instead behind the scenes
> in C++ working groups?

I find Kevlin's "More C++ Threading" paper is really good. Maybe we
should adapt Boost.Thread's implementation to this interface and check
if this is better than current one. But it's a quite big task.

> I've seen lots of excellent advise from Peter Dimov, Dave Abrahams and many
> others but is it the case that its just seen as too thorny a problem for
> individual's to commit to, or is Boost thread considered sufficient?

I'm not sure but some people have said they don't see boost-thread
interface as the best interface. But I don't know how many think that. I
personally prefer the "futures" approach described in Kevlin's paper.

> 2) Is Shmem being considered for the full-scale Boost library treatment as
> it appears to have a great deal of useful functionality to support existing
> OS threading and shared memory techniques.

Well, I'm developing Shmem and I'm a biased, but I do think that C++
world needs some serious inter-process library apart from threads. The
fact is that Shmem tries to offer a framework to put object in shared
memory, including STL container, but for this, I needed to develop basic
operating system wrappers. Not being a OS expert myself, I've took as
much as I could from Boost.Thread interface (locks, conditions...).

I have no idea about memory models so the current discussion for C++0x
is somewhat far from my knowledge, but in boost, we could try to define
some things about the interface:

-> Is boost threads interface sufficient or do we prefer kevlin's
approach? We can try to develop the second interface based on existing
Boost Thread's code.

-> We must define the synchronization objects. If we like boost thread's
approach, that's fine, but I would suggest that the use of lockers (like
scoped_lock) should be optional and not mandatory.

-> The same for thread local storage.

Apart from this, I would define more concepts:

-> A semaphore: Some say it's dangerous, but sometimes, a semaphore is
tha only way to notify events from drivers and interruptions. For me, a
semaphore is a must.

-> Define read-write locks interface definitively. Some have expressed
boost thread's approach is inefficient. Same with barriers.

-> Define a message queue. A message queue should be a must for a
serious C++ standard thread library. Should it use posix-like
priorities? System V approach?

-> We can even define a pipe, that can be used in a iostream-like
interface to pass data between threads/processes.

I would then adapt all Shmem stuff to the defined thread interface, so
we can use the same lockers with thread and process-wide mutexes. The
same with the inter-process message-queue. I would also separate
Shmem's low-level wrappers to a ipc library, so that Shmem just uses
them to offer STL-like shared memory containers, allocators and some
framework to create named objects. This way, we could split Shmem and
make reviews shorter.

Obviously, I would love to have also a unix socket-like ipc, but it
would be a serious development to emulate it in windows without using
TCP sockets.

I appreciate a lot boost libraries, but sometimes I think the libraries
are "expert level ideas", and that C++ is lacking basic blocks like
network, threads, processes, data-bases, and a GUI. Not that I have much
time, but I'm ready to help a bit in thread/process ideas.



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