Does io_service::post() block while io_service is busy?
I have a question about the behaviour of asio::io_service when it comes to executing previously posted work while trying to post even more work. I have two threads, one of which is the worker thread that runs io_service::run() and the other one that runs with a high priority and uses io_service::post() to relay processing of incoming requests via network to the worker thread (this has to be fast). The question is: When the worker thread is currently executing work (of which there may be a lot) which the high priority thread previously posted to it, is the io_service locked?; so that calls to io_service::post() block until the io_service is done? I came to this question because I saw that in ::post() there is a lock involved protecting access to the operations queue. Regards, Andreas -- Dipl.-Ing. (FH) Andreas Wehrmann Software Development -------------------------------------------------------------- Center Communication Systems GmbH A-1210 Wien, Ignaz-Köck-Straße 19 Sitz in Wien FN 796 88p, Firmenbuchgericht Wien www.centersystems.com Tel.: +43 (0) 190 199 - 3616 Mobile: +43 (0) 664 884 75916 Fax: +43 (0) 190 199 - 2110 E-Mail: a.wehrmann@centersystems.com
On Thursday, April 12, 2012 10:02 AM, Andreas Wehrmann wrote:
The question is: When the worker thread is currently executing work (of which there may be a lot) which the high priority thread previously posted to it, is the io_service locked?; so that calls to io_service::post() block until the io_service is done?
No. io_service::post will not block until the previous work items are done.
I came to this question because I saw that in ::post() there is a lock involved protecting access to the operations queue.
Although I'm not an expert of asio, I suspect io_service::run holds that lock for very short periods. Probably similar to the following pseudocode: 1: Wait until an operation is in the queue. 2: Acquire the lock. 3: Try to remove an operation from the operations queue. Don't wait if another thread already removed it between steps 1 and 2. 4: Release the lock. 5: Run the operation if we got one.
participants (2)
-
Andreas Wehrmann
-
Andrew Holden