Boost logo

Boost Users :

Subject: Re: [Boost-users] Simple threading question (I hope)
From: Mike Marchywka (marchywka_at_[hidden])
Date: 2008-11-06 13:56:16


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_faster_112008


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net