Re: [Boost-users] Simple threading question (I hope)

Subject: Re: [Boost-users] Simple threading question (I hope)
From: Alec Munro (amunro_at_[hidden])
Date: 2008-11-06 14:28:33

-----Original Message-----
From: boost-users-bounces_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] On Behalf Of Mike Marchywka
Sent: Thursday, November 06, 2008 2:56 PM
To: boost-users_at_[hidden]
Subject: Re: [Boost-users] Simple threading question (I hope)

Date: Thu, 6 Nov 2008 13:04:32 -0500
From: To: boost-users_at_[hidden]
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_at_[hidden]
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.