When to use threads

[JohnOne]

With my entry into programming being AutoIt, I learnt that extra

threads are not always necessary, even when sometimes I might

first think they are, and the same goes for Multiple processes.

Recently however, I recalled what first led me to this forum and AutoIt.

It was wanting to check the raw data that came through my ethernet device.

Someone mentioned wireshark, and that was that, a ready made solution

I did not need to script anything.

I have however revisited the packet analyses thing, and I'm using the ready made

library pcap (requires winpcap installed) in a C++ project.

The packets though come fast and at first I was parsing them in the event handler function

but it seemed to be missing or dropping packets, as though they were not being parsed

as fast as they were arriving.

So I had to read up on multithreading and used it.

My question is, is this a circumstance where threads are the best solution?

What I done was instead of parse the packet in the event handler, I start a new thread

from it and pass the thread the delivered packet to parse.

I've found that at any time there are no more than 7 or 8 threads concurrent, and I'm

also wondering if that seems like too many?

[Richard Robertson]

If you need raw speed you should not be using events and certainly not threads (unless you can successfully delegate which packets go to which threads which needs to be done on a single thread).

You should be polling with a large buffer and either starting a thread with that buffer or processing it quickly.

[JohnOne]

The packets are parsed in the order they are received and one thread does not begin to parse

data until the thread before it has ended (a thread id is passed in the same array as the data)

I opted for an event handler, because there may be periods of time when no packets are received

and thought a loop as tight as would be needed would be a waste of cycles.

[Valik]

You have a horrible design actually that is wasting more CPU cycles than you ever will with a polling solution. Thread creation and destruction is expensive. Besides, a quick look at the documentation shows that you can have pcap_next() block until it receives a packet or times out.

So no, this isn't really a good use of threading. The program should only have two threads, the first thread would be for the user-interface (This may not be required if you are using a console application). The second thread captures and processes all the packets and sends whatever important information back to the main thread to display. There is no need to add further threads for the pcap stuff.

[JohnOne]

Thank you gentlemen, I appreciate you time and advice.

I'll give polling method a go, and hopefully get better results.

[Valik]

That has what to do with this subject? That has what to do with multi-threading at all?

[JohnOne]

Just to confirm the advice was sound, got rid of the callback function and I have not

noticed any missing data, just using a loop.

Thank you again.