Re: [boost] Multi-processing - Boost future libraries?

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.

Regards,

Ion