[{"id":3518,"web_url":"https://patchwork.libcamera.org/comment/3518/","msgid":"<20200118232916.GD1124294@oden.dyn.berto.se>","date":"2020-01-18T23:29:16","subject":"Re: [libcamera-devel] [PATCH] libcamera: bound_method: Avoid\n\tdeadlock with ConnectionTypeBlocking","submitter":{"id":5,"url":"https://patchwork.libcamera.org/api/people/5/","name":"Niklas Söderlund","email":"niklas.soderlund@ragnatech.se"},"content":"Hi Laurent,\n\nThanks for your work.\n\nOn 2020-01-18 23:36:03 +0200, Laurent Pinchart wrote:\n> ConnectionTypeBlocking always invokes the method through inter-thread\n> message passing, which results in deadlocks if the sender and receiver\n> live in the same thread. The deadlock can easily be avoided by turning\n> the invocation into a direct call in this case. Do so to make\n> ConnectionTypeBlocking easier to use when some of the senders live in\n> the same thread as the receiver while the other senders don't.\n> \n> Extend the object-invoke test to cover this usage.\n> \n> While at it reformat the documentation to avoid long \\brief lines.\n> \n> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>\n> ---\n>  src/libcamera/bound_method.cpp | 22 ++++++++++++++--------\n>  test/object-invoke.cpp         | 20 ++++++++++++++++++++\n>  2 files changed, 34 insertions(+), 8 deletions(-)\n> \n> diff --git a/src/libcamera/bound_method.cpp b/src/libcamera/bound_method.cpp\n> index e18c2eb4c68e..9aa59dc3678f 100644\n> --- a/src/libcamera/bound_method.cpp\n> +++ b/src/libcamera/bound_method.cpp\n> @@ -35,16 +35,19 @@ namespace libcamera {\n>   * thread.\n>   *\n>   * \\var ConnectionType::ConnectionTypeQueued\n> - * \\brief The receiver is invoked asynchronously in its thread when control\n> - * returns to the thread's event loop. The sender proceeds without waiting for\n> - * the invocation to complete.\n> + * \\brief The receiver is invoked asynchronously\n> + *\n> + * Invoke the receiver asynchronously in its thread when control returns to the\n> + * thread's event loop. The sender proceeds without waiting for the invocation\n> + * to complete.\n>   *\n>   * \\var ConnectionType::ConnectionTypeBlocking\n> - * \\brief The receiver is invoked asynchronously in its thread when control\n> - * returns to the thread's event loop. The sender blocks until the receiver\n> - * signals the completion of the invocation. This connection type shall not be\n> - * used when the sender and receiver live in the same thread, otherwise\n> - * deadlock will occur.\n> + * \\brief The receiver is invoked synchronously\n> + *\n> + * If the sender and the receiver live in the same thread, this is equivalent to\n> + * ConnectionTypeDirect. Otherwise, the receiver is invoked asynchronously in\n> + * its thread when control returns to the thread's event loop. The sender\n> + * blocks until the receiver signals the completion of the invocation.\n>   */\n>  \n>  /**\n> @@ -71,6 +74,9 @@ bool BoundMethodBase::activatePack(std::shared_ptr<BoundMethodPackBase> pack,\n>  \t\t\ttype = ConnectionTypeDirect;\n>  \t\telse\n>  \t\t\ttype = ConnectionTypeQueued;\n> +\t} else if (type == ConnectionTypeBlocking) {\n> +\t\tif (Thread::current() == object_->thread())\n> +\t\t\ttype = ConnectionTypeDirect;\n>  \t}\n>  \n>  \tswitch (type) {\n> diff --git a/test/object-invoke.cpp b/test/object-invoke.cpp\n> index 8e2055ca620f..fa162c838c78 100644\n> --- a/test/object-invoke.cpp\n> +++ b/test/object-invoke.cpp\n\nNitpicking, to keep with our usual style should we not add a TC that \nfails before adding the fix?\n\nWith or without this changed,\n\nReviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>\n\n> @@ -100,6 +100,26 @@ protected:\n>  \t\t\treturn TestFail;\n>  \t\t}\n>  \n> +\t\t/*\n> +\t\t * Test that blocking invocation is delivered directly when the\n> +\t\t * caller and callee live in the same thread.\n> +\t\t */\n> +\t\tobject_.reset();\n> +\n> +\t\tobject_.invokeMethod(&InvokedObject::method,\n> +\t\t\t\t     ConnectionTypeBlocking, 42);\n> +\n> +\t\tswitch (object_.status()) {\n> +\t\tcase InvokedObject::NoCall:\n> +\t\t\tcout << \"Method not invoked for main thread (blocking)\" << endl;\n> +\t\t\treturn TestFail;\n> +\t\tcase InvokedObject::InvalidThread:\n> +\t\t\tcout << \"Method invoked in incorrect thread for main thread (blocking)\" << endl;\n> +\t\t\treturn TestFail;\n> +\t\tdefault:\n> +\t\t\tbreak;\n> +\t\t}\n> +\n>  \t\t/*\n>  \t\t * Move the object to a thread and verify that auto method\n>  \t\t * invocation is delivered in the correct thread.\n> -- \n> Regards,\n> \n> Laurent Pinchart\n> \n> _______________________________________________\n> libcamera-devel mailing list\n> libcamera-devel@lists.libcamera.org\n> https://lists.libcamera.org/listinfo/libcamera-devel","headers":{"Return-Path":"<niklas.soderlund@ragnatech.se>","Received":["from mail-lf1-x142.google.com (mail-lf1-x142.google.com\n\t[IPv6:2a00:1450:4864:20::142])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id F16116079E\n\tfor <libcamera-devel@lists.libcamera.org>;\n\tSun, 19 Jan 2020 00:29:17 +0100 (CET)","by mail-lf1-x142.google.com with SMTP id 9so21153376lfq.10\n\tfor <libcamera-devel@lists.libcamera.org>;\n\tSat, 18 Jan 2020 15:29:17 -0800 (PST)","from localhost (h-93-159.A463.priv.bahnhof.se. [46.59.93.159])\n\tby smtp.gmail.com with ESMTPSA id\n\tm16sm14553308ljb.47.2020.01.18.15.29.16\n\t(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n\tSat, 18 Jan 2020 15:29:16 -0800 (PST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=ragnatech-se.20150623.gappssmtp.com; s=20150623;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:content-transfer-encoding:in-reply-to;\n\tbh=49EGVLVVUHmBy0eNaKH5stbAX1XRUtq8F9ZuF/u+mrM=;\n\tb=WX3zxABef+yDuWoggiz5kjWwRNjIdyvf1Ax1wTzb/8+SfBv4gpV3GHzuaY1qfQuxe/\n\tVA3Sm9VIRoPGbf7fAYKetpFA+VpLpyz1DpO+/BBTnI97/0CJkFfH8TH2IhGMmbVgDH1V\n\tTp6BkY7F2/saGf4VQowZD6bJeagaNRkQXjHsSCcH3ZchmCqjE0hBmw2xRYqUcohA0fL/\n\tjNJXlDrdgrWIozAdCP5wyTFOTAWONADfYDxF1hAzLzkGQyfT6tnGFnF91VIFmrMBsXGb\n\t3JzhTegS/qt4oQ8TrOvW+MMPmMgp18GVjUQuWwxiZn1Vpkplr/hiSzk4H7N/WzTp9r5U\n\tIA4Q==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:content-transfer-encoding\n\t:in-reply-to;\n\tbh=49EGVLVVUHmBy0eNaKH5stbAX1XRUtq8F9ZuF/u+mrM=;\n\tb=k49v+TaFGPs3meLXsryPpsCRJR1tpKWRq3SD4wpciPub2rowwYrL3JwaK9Wts7z2w8\n\totTszM531UBMy0wTv2XtPdFCKYghUKB+2OOVxG/1Hij1UY0/hU+6enH5lex+Yp5r9Yu2\n\tXdJLf0fN5LcIJM2qX/1REvZwetjKa4koUr/x2aoDy+UAPXKRlnimk7s/doYQWgrJwhu6\n\tI3SYeptTbZEizG/xMPiTwq3mdcP7n6X7+r4eWpsLV+EdKwqzRtCCPk8ww79nacunq895\n\t5Bgg5Nu6bsfmNxF7oW5uTJX5luvnIdZj6GSCU4Fp4f+7RryNtih0ZDJNBeco3kq+Thde\n\tUSPw==","X-Gm-Message-State":"APjAAAXyQjZUIVdsjADue/9w8hWs3uTGSHHv2/wh/l7YE+Qs5dUCr176\n\t48Xaon5IEG2DcErHlH/wcjNmZg==","X-Google-Smtp-Source":"APXvYqy0+aYc5JdyX543pr2Ht/IUc+m7Yq69cJBgKJEN7LLcqAOgB3TZ0IumyfE8MYmNC3+OQzjagg==","X-Received":"by 2002:ac2:42ca:: with SMTP id\n\tn10mr6707643lfl.215.1579390157276; \n\tSat, 18 Jan 2020 15:29:17 -0800 (PST)","Date":"Sun, 19 Jan 2020 00:29:16 +0100","From":"Niklas =?iso-8859-1?q?S=F6derlund?= <niklas.soderlund@ragnatech.se>","To":"Laurent Pinchart <laurent.pinchart@ideasonboard.com>","Cc":"libcamera-devel@lists.libcamera.org","Message-ID":"<20200118232916.GD1124294@oden.dyn.berto.se>","References":"<20200118213603.16888-1-laurent.pinchart@ideasonboard.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20200118213603.16888-1-laurent.pinchart@ideasonboard.com>","Subject":"Re: [libcamera-devel] [PATCH] libcamera: bound_method: Avoid\n\tdeadlock with ConnectionTypeBlocking","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"<libcamera-devel.lists.libcamera.org>","List-Unsubscribe":"<https://lists.libcamera.org/options/libcamera-devel>,\n\t<mailto:libcamera-devel-request@lists.libcamera.org?subject=unsubscribe>","List-Archive":"<https://lists.libcamera.org/pipermail/libcamera-devel/>","List-Post":"<mailto:libcamera-devel@lists.libcamera.org>","List-Help":"<mailto:libcamera-devel-request@lists.libcamera.org?subject=help>","List-Subscribe":"<https://lists.libcamera.org/listinfo/libcamera-devel>,\n\t<mailto:libcamera-devel-request@lists.libcamera.org?subject=subscribe>","X-List-Received-Date":"Sat, 18 Jan 2020 23:29:18 -0000"}},{"id":3520,"web_url":"https://patchwork.libcamera.org/comment/3520/","msgid":"<20200119235441.GA4858@pendragon.ideasonboard.com>","date":"2020-01-19T23:54:41","subject":"Re: [libcamera-devel] [PATCH] libcamera: bound_method: Avoid\n\tdeadlock with ConnectionTypeBlocking","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Niklas,\n\nOn Sun, Jan 19, 2020 at 12:29:16AM +0100, Niklas Söderlund wrote:\n> On 2020-01-18 23:36:03 +0200, Laurent Pinchart wrote:\n> > ConnectionTypeBlocking always invokes the method through inter-thread\n> > message passing, which results in deadlocks if the sender and receiver\n> > live in the same thread. The deadlock can easily be avoided by turning\n> > the invocation into a direct call in this case. Do so to make\n> > ConnectionTypeBlocking easier to use when some of the senders live in\n> > the same thread as the receiver while the other senders don't.\n> > \n> > Extend the object-invoke test to cover this usage.\n> > \n> > While at it reformat the documentation to avoid long \\brief lines.\n> > \n> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>\n> > ---\n> >  src/libcamera/bound_method.cpp | 22 ++++++++++++++--------\n> >  test/object-invoke.cpp         | 20 ++++++++++++++++++++\n> >  2 files changed, 34 insertions(+), 8 deletions(-)\n> > \n> > diff --git a/src/libcamera/bound_method.cpp b/src/libcamera/bound_method.cpp\n> > index e18c2eb4c68e..9aa59dc3678f 100644\n> > --- a/src/libcamera/bound_method.cpp\n> > +++ b/src/libcamera/bound_method.cpp\n> > @@ -35,16 +35,19 @@ namespace libcamera {\n> >   * thread.\n> >   *\n> >   * \\var ConnectionType::ConnectionTypeQueued\n> > - * \\brief The receiver is invoked asynchronously in its thread when control\n> > - * returns to the thread's event loop. The sender proceeds without waiting for\n> > - * the invocation to complete.\n> > + * \\brief The receiver is invoked asynchronously\n> > + *\n> > + * Invoke the receiver asynchronously in its thread when control returns to the\n> > + * thread's event loop. The sender proceeds without waiting for the invocation\n> > + * to complete.\n> >   *\n> >   * \\var ConnectionType::ConnectionTypeBlocking\n> > - * \\brief The receiver is invoked asynchronously in its thread when control\n> > - * returns to the thread's event loop. The sender blocks until the receiver\n> > - * signals the completion of the invocation. This connection type shall not be\n> > - * used when the sender and receiver live in the same thread, otherwise\n> > - * deadlock will occur.\n> > + * \\brief The receiver is invoked synchronously\n> > + *\n> > + * If the sender and the receiver live in the same thread, this is equivalent to\n> > + * ConnectionTypeDirect. Otherwise, the receiver is invoked asynchronously in\n> > + * its thread when control returns to the thread's event loop. The sender\n> > + * blocks until the receiver signals the completion of the invocation.\n> >   */\n> >  \n> >  /**\n> > @@ -71,6 +74,9 @@ bool BoundMethodBase::activatePack(std::shared_ptr<BoundMethodPackBase> pack,\n> >  \t\t\ttype = ConnectionTypeDirect;\n> >  \t\telse\n> >  \t\t\ttype = ConnectionTypeQueued;\n> > +\t} else if (type == ConnectionTypeBlocking) {\n> > +\t\tif (Thread::current() == object_->thread())\n> > +\t\t\ttype = ConnectionTypeDirect;\n> >  \t}\n> >  \n> >  \tswitch (type) {\n> > diff --git a/test/object-invoke.cpp b/test/object-invoke.cpp\n> > index 8e2055ca620f..fa162c838c78 100644\n> > --- a/test/object-invoke.cpp\n> > +++ b/test/object-invoke.cpp\n> \n> Nitpicking, to keep with our usual style should we not add a TC that \n> fails before adding the fix?\n\nI've considered it, but this patch isn't a fix, it's an API behaviour\nchange that I think makes the ConnectionTypeBlocking more useful\n(instead of a 100% chance of deadlocking in a particular case, which is\ndocumented, it changes the behaviour to avoid having to handle that in\nthe caller).\n\n> With or without this changed,\n> \n> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>\n> \n> > @@ -100,6 +100,26 @@ protected:\n> >  \t\t\treturn TestFail;\n> >  \t\t}\n> >  \n> > +\t\t/*\n> > +\t\t * Test that blocking invocation is delivered directly when the\n> > +\t\t * caller and callee live in the same thread.\n> > +\t\t */\n> > +\t\tobject_.reset();\n> > +\n> > +\t\tobject_.invokeMethod(&InvokedObject::method,\n> > +\t\t\t\t     ConnectionTypeBlocking, 42);\n> > +\n> > +\t\tswitch (object_.status()) {\n> > +\t\tcase InvokedObject::NoCall:\n> > +\t\t\tcout << \"Method not invoked for main thread (blocking)\" << endl;\n> > +\t\t\treturn TestFail;\n> > +\t\tcase InvokedObject::InvalidThread:\n> > +\t\t\tcout << \"Method invoked in incorrect thread for main thread (blocking)\" << endl;\n> > +\t\t\treturn TestFail;\n> > +\t\tdefault:\n> > +\t\t\tbreak;\n> > +\t\t}\n> > +\n> >  \t\t/*\n> >  \t\t * Move the object to a thread and verify that auto method\n> >  \t\t * invocation is delivered in the correct thread.","headers":{"Return-Path":"<laurent.pinchart@ideasonboard.com>","Received":["from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 3915F60454\n\tfor <libcamera-devel@lists.libcamera.org>;\n\tMon, 20 Jan 2020 00:54:43 +0100 (CET)","from pendragon.ideasonboard.com (81-175-216-236.bb.dnainternet.fi\n\t[81.175.216.236])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id A8E05504;\n\tMon, 20 Jan 2020 00:54:42 +0100 (CET)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1579478082;\n\tbh=Qsew6PpU7RRq27d0BrGiTOQz5nBtL/9sQ8QInN3hFYg=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=AAjUOEGI5nJ0+zLeDriREeYxk13Dx5zkHrKpaa+tVksqZZUSVso9MHiGjoUYUgRwI\n\tA7r2MyQKJVkiVt/O4mfqsrLOe/uKU1kv2XMkAW9KlaEzLg7yB08BCMPafOxQ5yZxAJ\n\tq4meEayqqL67rSkbywDYy1/OQq3iK+uQIBNtcmDM=","Date":"Mon, 20 Jan 2020 01:54:41 +0200","From":"Laurent Pinchart <laurent.pinchart@ideasonboard.com>","To":"Niklas =?utf-8?q?S=C3=B6derlund?= <niklas.soderlund@ragnatech.se>","Cc":"libcamera-devel@lists.libcamera.org","Message-ID":"<20200119235441.GA4858@pendragon.ideasonboard.com>","References":"<20200118213603.16888-1-laurent.pinchart@ideasonboard.com>\n\t<20200118232916.GD1124294@oden.dyn.berto.se>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20200118232916.GD1124294@oden.dyn.berto.se>","User-Agent":"Mutt/1.10.1 (2018-07-13)","Subject":"Re: [libcamera-devel] [PATCH] libcamera: bound_method: Avoid\n\tdeadlock with ConnectionTypeBlocking","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"<libcamera-devel.lists.libcamera.org>","List-Unsubscribe":"<https://lists.libcamera.org/options/libcamera-devel>,\n\t<mailto:libcamera-devel-request@lists.libcamera.org?subject=unsubscribe>","List-Archive":"<https://lists.libcamera.org/pipermail/libcamera-devel/>","List-Post":"<mailto:libcamera-devel@lists.libcamera.org>","List-Help":"<mailto:libcamera-devel-request@lists.libcamera.org?subject=help>","List-Subscribe":"<https://lists.libcamera.org/listinfo/libcamera-devel>,\n\t<mailto:libcamera-devel-request@lists.libcamera.org?subject=subscribe>","X-List-Received-Date":"Sun, 19 Jan 2020 23:54:43 -0000"}}]