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