Need to find the right way to solve a problem in C#?

Question

.NET

Good afternoon!
There is a kind of simulator that works in a local network and exchanges data via a broadcast. You need to add maps to this simulator without touching the simulator itself, and display mobile objects.
The map application raises sockets in the same LAN and receives the necessary data packets (coordinates, etc.) of moving objects via udp ~ once a second, deserializes the data and displays the changes on the map.
There is little experience in c#, so I have difficulty how to organize the flow of such an application so as not to load the main stream, where the card itself is.
An example plan is as follows:
1. The application raises several sockets via Task.Run() and constantly (while true) receives udp packets. In the same task, the package is deserialized and added to the ConcurrentQueue.
2. Through Task.Run(), another thread is constantly trying to extract from the ConcurrentQueue; if successful, it extracts data from the queue, prepares maps for updating, and somehow tells the main thread to update the map.
3. The main thread updates the map.
Questions:
1. Did I understand correctly that it is better to send CPU-bound code to Task.run()?
2. Isn't ConcurrentQueue redundant here?
3. How to tell the main thread from Task.run() that everything is ready to update maps? I understand that there is a Task.Result, but if the Task is running all the time (while true), can I use it?

Well, or is my plan not there at all and is there a more elegant solution, taking into account the above?
Can someone share a similar example, I will be very grateful.

Answer 1

2. Isn't ConcurrentQueue redundant here?

Better use System.Threading.Channels instead ( https ://www.stevejgordon.co.uk/an-introduction-to -...)

3. How to tell the main thread from Task.run() that everything is ready to update maps? I understand that there is a Task.Result, but if the Task is running all the time (while true), can I use it?

With the help of a channel.
You shouldn't use Task.Result
Everything else sounds plausible