Should I make the class static or non-static for the following case?

Question

I have a class which has the purpose of providing file operations i.e. providing functionality to create the file, read, write and rewrite to the file. So, the main constituent of the class is functions.

However, there is one functionality where I am using a Timer to make the thread wait for one second. So, basically I have an AutoResetEvent and Timer working in conjunction.

Now, since we have to register the Timer_Elapsed callback to the Timer, we need a place to do it. Since the class is static, I can use a static constructor to do that but this makes me think whether the class should be static at first place.

I am confused whether to make the class static or non-static as it is mostly about giving simple functionality but at the same time Timer and AutoResetEvent have become kind of state elements of the class. I would appreciate suggestions.

Edit Reason why I am using a Timer is:

I am trying to synchronize file access between two processes by using FileShare.None. In order to do that I am in a loop to reattempt to gain access to the FileStream for which I have to wait 1 second each iteration. I am developing functionality in legacy code so I want to avoid Thread.Sleep. Also I know that a mutex would be a better option to synchronize access to a file but I cannot use it as I have so many such files that creating a mutex for each is not preferred (I am asked to not create mutex).

Answer 1

Turning this comment into an answer as OP accepted it as a viable answer.

---

I'm unsure about your reasoning to avoid Thread.Sleep (as per the comments on the answer) Are you expecting to run multithreaded?

• If no, then your single thread will always block for a second, regardless of how you do it.
• If yes, then sleeping one thread will not impact the other thread.

So in either case, I don't see a reason to discount Thread.Sleep as a viable solution.

---

In response to your comment:

@Flater yeah agree, but when we do Thread.Sleep we make the thread not reusable.

Note that await Task.Delay(1000); works equally well as Thread.Sleep(1000). However, if you are limited to a single thread, this can lead to your sleeping task to not be picked up for longer than a second.

Essentially, when you delay, the thread will look for another task to work on. However, it will not look back at the original task until its current task is being delayed as well. If the new task is long-running, then it may take some time for your original task to be picked up again.

But when you sleep (instead of delay), then the current tasks remains the current task, nothing else will be pickd up in the mean time, and the thread will resume after exactly a second.

Maybe that's okay, maybe it's not. I don't know enough about your circumstances to make that call. But consider which one is more appropriate for your case.

Answer 2

I've read you mention the codebase is legacy.

I came up with a workaround.

Since this operation is inside of a Thread.

Thread.Sleep could be another way for waiting one second, and you don't have to deal with timer.

Sorry, I can't comment it for less than 50 reputation.

Answer 3

In C++, if you have a static instance of a class, and exit the application, the destructor for the class will be called, possibly while the static instance is still running other code, with possibly fatal results.

I would avoid static instances especially when timers or anything multithreaded is involved.