Peter Dimov wrote:
There is also the option of implementing pthread_rwlock_* on Windows, keeping the higher layer platform-independent. This obviously requires a higher layer that agrees with the pthread_rwlock_* interface.
Sorry, but I am not sure If I understand what you mean. Do you mean the windows version should be implemented on top of pthread? In the platform split I took the following route: 1) Native platform API: this means win32API on windows, pthread where pthread is considered native possibly native linux, i.e. semaphores, fork, NPTL, ... 2) pthread API: For every platform where a pthread lib is available provide a pthread variant. I.e.: pthreads-win32, pthread on linux, pthread OSX, ... In the end the user may choose from 2 library variants on platforms that have both API's available. If I may understand your sentence in this respect: Yes of course, we should and will do this on windows. Roland