Roland Schwarz <roland.schwarz@chello.at> writes:
Anthony Williams wrote:
That was when the goal was a simple reimplementation under the BSL. Now Bill's code is under the BSL, the goalposts have moved to focusing on a potential interface for the new standard. Are you in agreement that this is a worthwhile goal?
Well, yes in principle, but what about the ongoing platform split? It is not finished yet.
We likely need a platform split whatever interface we go with, since pthreads is quite different at the API level to Windows, even if the same facilities are on offer. What's left to do? How can I help?
And then we should concentrate on getting 1.34 ready shouldn't we?
If there's something that needs doing for 1.34, it should take priority. I really was under the impression that there was nothing to do here, since the existing code is now under the BSL, and the tests all pass. Are them outstanding bugs that need fixing? Am I missing something? I had missed the fact that the existing rwmutex was still there, even though it was removed from 1.33, so it's quite possible that I'm missing something else too.
I have to say that it is a rather thankless task to do the work for the split, just to possibly see that everything is superfluous, because we are doing a new interface. (I am also just doing this in my spare time, and I also rather like thinking about new stuff.)
Sorry you're finding it thankless. How can I help?
I am really inclined to abandon work on thread_rewrite if we instead opt. to concentrate on a new interface.
It would be a shame if we lost you. Wouldn't you be interested in developing the new interface?
If you would like , I'll be happy to oblige.
Possibly yes :-)
OK, I'll try and draft something. No doubt it will make things clearer to me, too.
I am not sure we need separate types for try_ and timed_ variants of a given mutex, but if we need them for one platform (because a mutex without the options can be simplified), it might be worth providing typedefs or delegating classes for other platforms.
Why not simply class scoped_lock class scoped_try_lock : public scoped_lock class scoped timed_lock : public scoped_try_lock
Or are you afraid of the virtual functions this implies?
The scoped_xxx_lock classes all have slightly different interfaces at the moment, which makes me a bit uncomfortable. For example, a scoped_try_lock constructed with a mutex may or may not lock, whereas a scoped_lock constructed with a mutex always locks, and a scoped_timed_lock cannot be constructed with just a mutex. OTOH, all three scoped_xxx_lock classes have a constructor that takes a bool as a second parameter and will always lock if that parameter is true. However, that wasn't what I was referring to. I was thinking about mutex, try_mutex and timed_mutex, which I think can really be one and the same class. Empty inheritance works fine if you want distinct types, provided you don't need them to be POD. recursive_mutex requires a recursion count, so can justify being a separate class. For read/write mutexes, a simple read/write implementation is simpler than an upgradeable one (and in my implementation requires one less semaphore) so it might make sense to have two varieties. Howard calls them shar(e)able_mutex and upgrad(e)able_mutex in N2094. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk