Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Ian Kelly <ian.g.kelly@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: Bi-directional sub-process communication
Date: Mon, 23 Nov 2015 13:51:51 -0700
Lines: 68
Message-ID: <mailman.75.1448311953.2291.python-list@python.org>
References: <B819AD72-C0F9-4E6C-992A-5E5556979883@ravnalaska.net> <CALwzidkz6LdFeXsRZW1sAYxXvJGRX5KA5XsM4T0dEOb34C9HDQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <CALwzidkz6LdFeXsRZW1sAYxXvJGRX5KA5XsM4T0dEOb34C9HDQ@mail.gmail.com>
Precedence: list
Xref: csiph.com comp.lang.python:99281

On Mon, Nov 23, 2015 at 12:55 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Mon, Nov 23, 2015 at 10:54 AM, Israel Brewster <israel@ravnalaska.net>=
 wrote:
>> Concern: Since the master process is multi-threaded, it seems likely eno=
ugh that multiple threads on the master side would make requests at the sam=
e time. I understand that the Queue class has locks that make this fine (on=
e thread will complete posting the message before the next is allowed to st=
art), and since the child process only has a single thread processing messa=
ges from the queue, it should process them in order and post the responses =
(if any) to the master_queue in order. But now I have multiple master proce=
sses all trying to read master_queue at the same time. Again, the locks wil=
l take care of this and prevent any overlapping reads, but am I guaranteed =
that the threads will obtain the lock and therefore read the responses in t=
he right order? Or is there a possibility that, say, thread three will get =
the response that should have been for thread one? Is this something I need=
 to take into consideration, and if so, how?
>
> Yes, if multiple master threads are waiting on the queue, it's
> possible that a master thread could get a response that was not
> intended for it. As far as I know there's no guarantee that the
> waiting threads will be woken up in the order that they called get(),
> but even if there are, consider this case:
>
> Thread A enqueues a request.
> Thread B preempts A and enqueues a request.
> Thread B calls get on the response queue.
> Thread A calls get on the response queue.
> The response from A's request arrives and is given to B.
>
> Instead of having the master threads pull objects off the response
> queue directly, you might create another thread whose sole purpose is
> to handle the response queue. That could look like this:
>
>
> request_condition =3D threading.Condition()
> response_global =3D None
>
> def master_thread():
>     global response_global
>     with request_condition:
>         request_queue.put(request)
>         request_condition.wait()
>         # Note: the Condition should remain acquired until
> response_global is reset.
>         response =3D response_global
>         response_global =3D None
>     if wrong_response(response):
>         raise RuntimeError("got a response for the wrong request")
>     handle_response(response)
>
> def response_thread():
>     global response_global
>     while True:
>         response =3D response_queue.get()
>         with request_condition:
>             response_global =3D response
>             request_condition.notify()

Actually I realized that this fails because if two threads get
notified at about the same time, they could reacquire the Condition in
the wrong order and so get the wrong responses.

Concurrency, ugh.

It's probably better just to have a Condition/Event per thread and
have the response thread identify the correct one to notify, rather
than just notify a single shared Condition and hope the threads wake
up in the right order.