Simple threading question (I hope)
Hi List, I'm fairly new to multithreading, especially in C++. Things seem generally straightforward when using boost::thread, but there was one question I had. I have a mutex that I use to control access to a data processing object. Whenever I receive new data, I attempt to lock the mutex, and process it. However, I think it's possible that I might receive several data packets while I'm processing, and it's important that these packets are processed in order. So I suppose my question is, when a mutex is unlocked, how is it determined which thread gets to lock it next? Thanks, Alec Munro --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Date: Thu, 6 Nov 2008 13:04:32 -0500 From: To: boost-users@lists.boost.org Subject: [Boost-users] Simple threading question (I hope) Hi List, I’m fairly new to multithreading, especially in C++. Things seem generally straightforward when using boost::thread, but there was one question I had. I have a mutex that I use to control access to a data processing object. Whenever I receive new data, I attempt to lock the mutex, and process it. However, I think it’s possible that I might receive several data packets while I’m processing, and it’s important that these packets are processed in order. So I suppose my question is, when a mutex is unlocked, how is it determined which thread gets to lock it next? [ can't get hotmail to ">" reliably, sorry ] If you knew you probably wouldn't be using threads, LOL. I'm not sure I understand, you are expecting a bunch of packets so you launch one thread per expected packet and wait, hoping they respond in order? You use threads when you have many processors or asynchrnous events and you hope the underlying scheduling and event system does something nice to maximize system throughput. If you have a single udp packet stream or connection, it is probably easier to handle the packets as they arrive and sort them out synchronously. You could consider something like a circular buffer, and use standard locking paradigms , and sort them out after you read them on a single thread with not additional concurrency issues. I guess you could hold a given packet in a small sorting queue until all the priors have arrived. I guess you could spawn threads for each missing packet, have one "main" thread that spawns children until all the prior packets have been queued, but it sounds like a mess with little benefit. Since packets arrive serially even if unpredictably, you can do this all on one thread. If you do launch a thread for each packet, they would probably be better off locking with a buffer than with each other ( writes performed as recieved, sorted upon readout ). This is different from multiple streams or connections. I confess ignorance on boost, having only used the regex stuff, but I'd like to understand what other's are doing so I know what to look for when evaluating options later. However, I have dealt with RTSP and some limited packet processing before. [end missing ">" ] Thanks, Alec Munro--------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _________________________________________________________________ Windows Live Hotmail now works up to 70% faster. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster_...
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Mike Marchywka Sent: Thursday, November 06, 2008 2:56 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Simple threading question (I hope) Date: Thu, 6 Nov 2008 13:04:32 -0500 From: To: boost-users@lists.boost.org Subject: [Boost-users] Simple threading question (I hope) Hi List, I'm fairly new to multithreading, especially in C++. Things seem generally straightforward when using boost::thread, but there was one question I had. I have a mutex that I use to control access to a data processing object. Whenever I receive new data, I attempt to lock the mutex, and process it. However, I think it's possible that I might receive several data packets while I'm processing, and it's important that these packets are processed in order. So I suppose my question is, when a mutex is unlocked, how is it determined which thread gets to lock it next? [ can't get hotmail to ">" reliably, sorry ] If you knew you probably wouldn't be using threads, LOL. I'm not sure I understand, you are expecting a bunch of packets so you launch one thread per expected packet and wait, hoping they respond in order? You use threads when you have many processors or asynchrnous events and you hope the underlying scheduling and event system does something nice to maximize system throughput. If you have a single udp packet stream or connection, it is probably easier to handle the packets as they arrive and sort them out synchronously. You could consider something like a circular buffer, and use standard locking paradigms , and sort them out after you read them on a single thread with not additional concurrency issues. I guess you could hold a given packet in a small sorting queue until all the priors have arrived. I guess you could spawn threads for each missing packet, have one "main" thread that spawns children until all the prior packets have been queued, but it sounds like a mess with little benefit. Since packets arrive serially even if unpredictably, you can do this all on one thread. If you do launch a thread for each packet, they would probably be better off locking with a buffer than with each other ( writes performed as recieved, sorted upon readout ). This is different from multiple streams or connections. I confess ignorance on boost, having only used the regex stuff, but I'd like to understand what other's are doing so I know what to look for when evaluating options later. However, I have dealt with RTSP and some limited packet processing before. [end missing ">" ] Thanks, Alec Munro------------------------------------------------------------------- -- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _________________________________________________________________ Windows Live Hotmail now works up to 70% faster. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_fas ter_112008 _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users Thanks for your response, but I don't believe it is applicable to my question. Perhaps if I explain my problem in a little more detail... I've got a COM dll that communicates over USB. It relies on a specific USB driver for communication. When I initiate communication with the USB driver, I can register an object to accept notifications of USB events. Each of these notifications occurs on a new thread. When this object receives a "new data" event, I read the data from the USB channel, and then send the data to a different object to be processed. This looks like this: boost::mutex::scoped_lock channel_lock(channel_mutex); { _channel->ReadPacket((unsigned char *)buffer, BUFFER_LENGTH, &read_count); data = (char *)((DEVICE_DATA*)buffer)->data; } boost::mutex::scoped_lock client_lock(client_mutex); { _client.processMessage(data); } My question is if I receive several packets while I am in processMessage(), will those packets be passed to processMessage() in the order they arrive? Thanks, Alec --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
AMDG Alec Munro wrote:
I've got a COM dll that communicates over USB. It relies on a specific USB driver for communication. When I initiate communication with the USB driver, I can register an object to accept notifications of USB events. Each of these notifications occurs on a new thread.
When this object receives a "new data" event, I read the data from the USB channel, and then send the data to a different object to be processed. This looks like this:
boost::mutex::scoped_lock channel_lock(channel_mutex); { _channel->ReadPacket((unsigned char *)buffer, BUFFER_LENGTH, &read_count); data = (char *)((DEVICE_DATA*)buffer)->data; }
boost::mutex::scoped_lock client_lock(client_mutex); { _client.processMessage(data); }
My question is if I receive several packets while I am in processMessage(), will those packets be passed to processMessage() in the order they arrive?
I don't see how you can guarantee this. Suppose that that thread A reads the data and is then pre-empted. Thread B, then reads its data and continues on to process it. Thread A now processes its data. Even if threads acquire the mutex in the same order that they reach it (which is not guaranteed), how do you guarantee that they reach the mutex in the right order? In Christ, Steven Watanabe
Take a look at the bounded_buffer example in the circular_buffer documentation. Rodrigo P.S. Steve, why the AMDG in all of your emails?
Thanks for the responses, Rodrigo and Steve! I hadn't even considered that one of the threads might be pre-empted before it locked the client_mutex, but after it read the data. I'll rethink my implementation a little bit and see if I can get around that. Alec ________________________________ From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Rodrigo Madera Sent: Thursday, November 06, 2008 6:53 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Simple threading question (I hope) Take a look at the bounded_buffer example in the circular_buffer documentation. Rodrigo P.S. Steve, why the AMDG in all of your emails? --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
This is quite close to being a political rant but I thought it was worth the risk of annoying the moderator :) Many people ask about threads, presumably trageting single or maybe 2-4 core processors, expecting a speed up proportional to the number of threads. I keep posting questions about boost support for cache or at least memory awareness and the needs for locality ( IIRC, it was hard to keep an early 2 core hyperthread chip fed without a little help from vtune ). The graph here is quite dramatic ( but I think their units "seconds" needs a minus one if you believe the text, in any case the red curve is NOT monotonic ): http://www.spectrum.ieee.org/nov08/6912 "At the heart of the trouble is the so-called memory wall—the growing disparity between how fast a CPU can operate on data and how fast it can get the data it needs. Although the number of cores per processor is increasing, the number of connections from the chip to the rest of the computer is not. So keeping all the cores fed with data is a problem. In informatics applications, the problem is worse, explains Richard C. Murphy, a senior member of the technical staff at Sandia, because there is no physical relationship between what a processor may be working on and where the next set of data it needs may reside. Instead of being in the cache of the core next door, the data may be on a DRAM chip in a rack 20 meters away and need to leave the chip, pass through one or more routers and optical fibers, and find its way onto the processor. " So, as you design apps or libary code, think globally and act locally. Don't assume that an ignorant but hopefully "fair" thread scheduler will save you from cache thrashing that should be fixed by more attention to algorithm design. Mike Marchywka 586 Saint James Walk Marietta GA 30067-7165 415-264-8477 (w)<- use this 404-788-1216 (C)<- leave message 989-348-4796 (P)<- emergency only marchywka@hotmail.com Note: If I am asking for free stuff, I normally use for hobby/non-profit information but may use in investment forums, public and private. Please indicate any concerns if applicable. Note: hotmail is getting cumbersom, try also marchywka@yahoo.com _________________________________________________________________ See how Windows® connects the people, information, and fun that are part of your life http://clk.atdmt.com/MRT/go/119463819/direct/01/
participants (4)
-
Alec Munro -
Mike Marchywka -
Rodrigo Madera -
Steven Watanabe