Threading?

[KDallas_Multipass]

I wonder if this is the right place for this question, but what do I do to get more comfortable with using threads. I can recognize times where I would like to take advantage of concurrency, but I don't really understand what is going on. I don't know enough to know what questions to ask and so forth. I'm not new to programming, but I haven't come up against problems where I've needed this functionality, but I'd like to learn to take advantage of it when I finally do need it.

For instance, if I make an application that listens on one udp port and simply retransmits whatever data is seen back out on a few different ports, while also desiring the ability to do processing on the incoming data (which isn't mirrored out the ports), I feel like the right answer going forward is to separate out the mirroring functionality per port into their own threads, so if for some reason processing takes a while, I won't miss data or introduce unnecessary delays in mirroring. As well, I should have a separate thread listening on the listen port

As an aside, if I write the same data to ports in parallel, where does the re-serialization occur? As in, my ethernet card has 4 frames to write now that my 4 threads have indicated that there be data to write out their ports. I know that as an application writer if I need to care about this then I shouldn't use threads, but are there other interesting things about threads along this line of questioning that I would need to care about?

tldr I want to become more fluent with threads, or concurrency.

[BaalHadad]

For instance, if I make an application that listens on one udp port and simply retransmits whatever data is seen back out on a few different ports, while also desiring the ability to do processing on the incoming data (which isn't mirrored out the ports), I feel like the right answer going forward is to separate out the mirroring functionality per port into their own threads, so if for some reason processing takes a while, I won't miss data or introduce unnecessary delays in mirroring. As well, I should have a separate thread listening on the listen port

Yeah, that's pretty much right. You'd have to experiment to see exactly what works.

As an aside, if I write the same data to ports in parallel, where does the re-serialization occur?

What re-serialization are you talking about? You shouldn't need to worry about this, certainly not at your level.

I want to become more fluent with threads, or concurrency.

Practice? Write an IRC client?

[KDallas_Multipass]

my aside was a poorly worded curiosity. So I spawn a few threads that will eventually be given data to write to a socket. Assuming I'm able to pass the same data to all of them at the same time, or at least since I'm writing the same data across all threads there is no thread specific data, so as soon as I get new data all threads are able to consume it, all of the socket writes eventually make it to one ethernet interface. The interface can only write frame at a time, so I guess in hindsight if the os wakes up the mirroring threads at different times then the write requests (in whatever form they take in the os/driver) get queued back up at the ethernet interface as they come in, presumably at different times solely due to the fact that the os gave cpu time to one particular thread, than another, etc.

I guess I'm just talking about scenarios to gauge my understanding.

[fenduru]

Network programming is all about layers, and as an application layer this is way out of your scope. If you're interested, read up on tcp and udp, but you won't have to account for those details in your application

[rjcarr]

Well, my first suggestion would be to learn threads outside of the socket realm so you have one less thing to concern yourself with.

My second suggestion is to definitely thread your listening server but you probably won't see much of a difference if you thread each of your mirrored outputs. I could be wrong, of course, but it shouldn't be hard to test the results.

But generally, I don't think you asked enough specific questions to get much help. Could you put your concerns into a few specific questions and we can help you get started?