Hi,

On 16/2/24 上午1:39, Piotr Caban wrote:
On 02/23/16 18:12, YongHao Hu wrote:
As we can refer to some implementation of Microsoft[1], do you think it
would become easier?
I didn't look on it yet so I have no clue if it's going to be helpful. Probably yes.

For example, the event class[2] can refer to the pplxlinux.h[3],
TaskCollection[4] can refer to pplx.h[5] and
reader_writer_lock[6] can refer to pplxlinux.h[7] etc.
You can get similar information from C++ standard description. You can get some basic information from there but wine's implementation will need to be binary compatible (or at least structures will need to have the same size as on windows).

I want to mention that even the structures, class and functions have implementation in the open-source project.[1,2,3]
For example, in [1], as far as I am concerned, we can implement Class event in Wine base on this. Of course, we also need to be binary compatible.
  class event_impl {
        private:
            cpprest_synchronization::mutex _lock;
            cpprest_synchronization::condition_variable _condition;
            bool _signaled;
        public:
            static const unsigned int timeout_infinite = 0xFFFFFFFF;
            event_impl() : _signaled(false) { }
            void set() {
                cpprest_synchronization::lock_guard<cpprest_synchronization::mutex> lock(_lock);
                _signaled = true;
                _condition.notify_all();
            }
            void reset() {
                cpprest_synchronization::lock_guard<cpprest_synchronization::mutex> lock(_lock);
                _signaled = false;
            }
            unsigned int wait(unsigned int timeout) {
                cpprest_synchronization::unique_lock<cpprest_synchronization::mutex> lock(_lock);
                if (timeout == event_impl::timeout_infinite) {
                    _condition.wait(lock, [this]() -> bool { return _signaled; });
                    return 0;
                } else {
                    cpprest_synchronization::chrono::milliseconds period(timeout);
                    auto status = _condition.wait_for(lock, period, [this]() -> bool { return _signaled; });
                    _ASSERTE(status == _signaled);
                    // Return 0 if the wait completed as a result of signaling the event. Otherwise, return timeout_infinite
                    // Note: this must be consistent with the behavior of the Windows version, which is based on WaitForSingleObjectEx
                    return status ? 0: event_impl::timeout_infinite;
                }
        };



My simple plan may like this:
     Add tests to critical session.
     Implement Class condition variable first, which can refer to BOOST
and tests.
     Implement Class event and tests.
     Implement Class TaskCollection and tests.
     Implement Class reader_writer_lock and tests.
     Else: Find something that I think I can handle.

Do you think such a plan would satisfy GSoC's requirement?
Sorry, I don't know much about Concurrency namespace yet. I just wanted to warn you that it may be harder then you expect. 

Thank you for your attention. I will consider it deeply.


[1]: https://github.com/Microsoft/cpprestsdk/blob/master/Release/include/pplx/pplxlinux.h#L84
[2]: https://github.com/Microsoft/cpprestsdk/blob/master/Release/include/pplx/pplx.h#L146
[3]: https://github.com/Microsoft/cpprestsdk/blob/master/Release/include/pplx/pplxlinux.h#L140