What is the best way to write a class for managing saving data to multiple files?

Question

.NET

I welcome everyone.
I am solving the following problem: It is necessary to write a class that accepts data from multiple clients and independently serializes the data into the appropriate files. Data - structures or classes described in the project.
Also, upon request from the client, the class returns deserialized data from the file.
All communication is done through the event mechanism.
I figured out everything except threading. Since I had never worked with them before, I immersed myself in articles and frankly got confused. The abundance of options described in MSDN inspires)
Therefore, I ask you to help with advice and indicate where I made a mistake in my reasoning.
1) So, the class should not stop its work and should continue to receive signals. but you cannot write to or read data from a file that is currently being occupied by another thread. I have a list of files, is it enough for me to add a busy/not busy flag to each of them so that the threads check for it and wait some time before trying to write again? Or are there more advanced and flexible approaches?
2) Events happen often. Therefore, it is pointless to constantly create and kill threads - performance will drop significantly due to the constant change of context. However, the process of writing and reading to a file can take a long time. It begs to use async/await - one thread for one file. Moreover, after the task is completed, the thread must wait for new data. Questions:
a_0) Do I really need asynchrony here? Wouldn't I achieve the same results by having separate parallel threads?
a) How competent is it to give each thread a queue of input data so that when new data arrives, it picks them up and saves them to a file? And the rest of the time in an infinite loop polls the queue for the presence of elements.
I like this option because once the created thread will work without interfering with the main one + the interaction of threads is limited to sharing access to the queue. Where am I wrong?
b) The second option has a different logic. Each thread performs a task and then goes to sleep. The main thread receives data on events, stores them in a queue and waits for the required thread to become free. Then, when the desired thread is released, it calls it and passes the arguments - an array of data.
Will it make the job easier and which is better in terms of performance?
c) Improvement of option B - instead of a direct call to the thread and passing data to it, an event is used. Why is this option better/worse than the others?
Other questions:
3) Is it possible to store a list of asynchronous threads? if so, how?
4) How to put an asynchronous thread on waiting?

Answer 1

I like option a. A thread-safe queue is not a myth, it is a very real task. The only thing I would add is that since the files can be processed for a long time, then I would add 1-2 more streams there. Let them sort it out if one is busy. It's just not very clear to me what to do if the files are different, but have the same name (1.jpg for example). Whether the client receives a file identifier by which to pick it up later, or by the phases of the moon, he will have to guess which file he needs.

Answer 2

Other questions:
3) Is it possible to store a list of asynchronous threads? if so, how?
4) How to put an asynchronous thread on waiting?

3. You can. thread pool.
4. Thread.Sleep(2000) or await Task.Delay(2000). But it's better to return it to the system, let it do something smart on it.
Simply put - Plinq . It knows a little about the system (what exactly you have) and will not run more threads than it needs. It may also not parallel at all.
With a large amount of work, the Task heap is slower. But a bunch of tasks will eat up a bunch of memory and will allocate threads for 20 seconds.
But it's simple. You write a simple iteration in linq and then add a couple of letters.
Also cool and short - System.Collections.Concurrent . Thread-safe collections.