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 haven't seen Kevlin's paper. All I can find is http://www.two-sdg.demon.co.uk/curbralan/papers/accu/MoreC++Threading.pdf. IIUC, futures are a very useful high-level abstraction but you can't solve all the same problems with them as you can with the facilities of Boost.Threads. 'Course, I could be wrong, but that paper doesn't mention condition variables anywhere so I can't tell.
Sorry, for the word "paper". I was talking about that pdf. Maybe is not enough, but we could offer both interfaces, and kevin's approach like a wrapper over Boost.Thread. Conditions variables are not mentioned but they could be the same as Boost.Thread, I find them very useful.
Yes. Especially considering that threads and processes are, um, different ;) However, it would be very useful to have some common abstractions that allow one to move between the two with little or no pain.
That's why I would like to share some utilities like scoped_locks and make the interface very similar (mutexes, locks, etc...)
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.
Is it possible to abstract away any of the "unsafety" without losing applicability to the crucial use cases?
Umm, we have a lot to think here.
-> 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.
Nifty.
I will try to define the interface of both classes. I would not reinvent the wheel, we have posix message queues and unix pipes, that work great and semantics are known. Maybe atomic write issues with pipes could be simplified, since we have a message queue, for the messages, and use the pipe like a stream oriented, unstructured flow.
What we really need is someone/people to step up to the plate and take responsibility for development, maintenance, and documentation of relevant libraries. We need more than ideas; we need leadership. That isn't to say it has to be done by one person alone, but at least someone needs to rally the energy of Boosters with the interest and expertise to tackle the problems. Maybe you and Paul can do something together?
I'm ready to make a new Shmem snapshot, stop the development of Shmem (well trivial bug-fixes only) and work on Boost Thread's interface. Not that I am an expert in threads, I'm talking just about the interface, but at least I will start making noise about this. If we have a definitive boost thread interface, I would then adapt Shmem to this interface. Last time I looked, Michael Glassford was mantaining Boost.Thread, and he had good ideas, so he could help a lot here. Regards, Ion