如何暂停线程池中线程的执行一段时间而不完全阻塞线程？

Question

What I have is something similar to this:

//method being called by thread pool thread
public string someFunction(){
    string someString = "string";

    //Stuff happens

    //Need to wait for 5 seconds without blocking thread

    return someString;
}

The issue is that I need the result of that method returned to the method that called it, however, I do not want it returned immediately and I do not want to block the thread. Is there a way that I can make the thread pause at that line for a specified amount of time and release the thread back into the thread pool, and then after some timeout, one of the thread pool threads picks up where it left off and completes the function and returns?

---

All... After spending some time with your responses, I realize now that doing what I am trying to achieve is not so much possible in the context in which I want it.

A little explanation though. I am trying to create a rudimentary long poll web server in c sharp for a web based chat application I am building. I was wanting to have the thread enter a method where it waits until one of two things happens, either data shows up for the client, or a poll timeout occurs. However, I did not want the thread to block, I have some time in the past implemented something where each client got a thread and the thread blocked and trust me... it is NOT a good idea. The 5 seconds in the example was arbitrary and the actual time will likely sit somewhere between 1 and 5 minutes. In the end, the structure I may end up going with is a sort of client management thread. a thread that works its way through a list asking each client if the client has work to be done. If the client has reached its timeout or has data waiting in its queue, then the appropriate method gets dispatched into the thread pool and and the Client Management thread continues on to the next client.

Something like so...

while(true){
    foreach(Client client in ClientList){
        //check if the client has something it needs done
        if(client.needsWork){
               //invoke the appropriate method asynchronously
               delegate = client.appropriateInvokable;
               delegate.beginInvoke();
        }
    }
}

Thank you all considerably for your help and patience!

Answer 1

After looking through your question, I see it's a bit trickier than just getting a timer callback on a new thread. The real issue is that your call is structured to return a value synchronously, so there is no way you can avoid blocking the calling thread. The correct way to avoid blocking is to change your call to use an asynchronous callback rather than returning the value directly. If you have access to the TPL, one nice way to do this is to return a Task object that the caller can then Wait on immediately or register for a callback.

---

That said, for the timing callback aspect, I have some utility code that I use to simplify working with System.Threading.Timer in these one-off timer scenarios. I've cut it down to the specified functionality and put it below:

public sealed class TimerService
{
    /// <summary>
    ///   This method registers a call back to be called after a specified period of time.
    /// </summary>
    /// <param name = "duration">The duration after which to call back</param>
    /// <param name = "callback">The method to call back</param>
    public void WhenElapsed(TimeSpan duration, Action callback)
    {
        if (callback == null) throw new ArgumentNullException("callback");

        //Set up state to allow cleanup after timer completes
        var timerState = new TimerState(callback);
        var timer = new Timer(OnTimerElapsed, timerState, Timeout.Infinite, Timeout.Infinite);
        timerState.Timer = timer;

        //Start the timer
        timer.Change((int)duration.TotalMilliseconds, Timeout.Infinite);
    }

    private void OnTimerElapsed(Object state)
    {
        var timerState = (TimerState)state;
        timerState.Timer.Dispose();
        timerState.Callback();
    }

    private sealed class TimerState
    {
        public TimerState(Action callback)
        {
            Callback = callback;
        }

        public Timer Timer { get; set; }

        public Action Callback { get; private set; }
    }
}

Answer 2

using System.Threading.Timer Class. Refer to the above MSDN link.

Answer 3

The accepted answer was what I needed also, though after looking at it a little I think we can reduce it down to just this. And it seemed appropriate to name it after that JScript functions we all know and love...

public static void SetTimeout(Action callback, int milliseconds)
{
    Timer t = null;
    t = new Timer((state) => { t.Dispose(); callback(); }, null, dueTime: milliseconds, period: Timeout.Infinite);
}
public static Timer SetInterval(Action callback, int milliseconds)
{
    return new Timer((state) => { callback(); }, null, dueTime: milliseconds, period: milliseconds);
}
public static void ClearInterval(Timer t)
{
    t.Dispose();
}

Answer 4

To really not block, stay on the same thread, and wait 5 seconds...

var until = Environment.TickCount + 5000;
while(Environment.TickCount < until);

There goes one of your CPUs for 5 seconds! I really hope you don't have a single core available to the process.

Still, that's what it means to have a thread wait for 5 seconds without blocking. A thread that isn't waiting on something is using CPU time. While we strive to have our CPUs busy as long as there is work for them to be doing, we strive to have them to be busy with real work.

Sometimes code similar to the above is used for very small pauses on the order of nanoseconds, to avoid context switches when the condition the thread wants to see before progressing is likely to happen soon.

This is of no value here, since a thread's time slice is typically in the range of 20ms to 180ms, it's clearly going to be up within the 5second period.

While we often want to avoid threads blocking, and may go to considerable lengths to avoid it, in this case if we really have to stay on the same thread, then we're a waste of CPU and are going to context-switch anyway, so really the sooner we block the better. The simplest way of doing this would be Thread.Sleep(5000) .

Alternatively, having failed to deliver one of the three requirements (don't block, stay on the same thread and return to the method synchronously, cause a 5 second delay) by blocking, we can change to delivering another two.

If we use a call-back then we won't be returning the value to the calling thread, but we will prevent threads from blocking unnecessarily, and this is probably the best over-all approach. This will require more restructuring though.

Of course, if we can work out a way to avoid the other of the three requirement, that we wait 5 seconds at all, then all the other problems go away and we're 5 seconds faster!

Both of these last two approaches are better than anything involving Thread.Sleep (98% of code that calls that is something that can be improved somewhere, and close to 100% of code that calls it with a value higher than around 2 is). It's hard to give clear advice on just how to do this without more context as to why you need to wait 5seconds in the first place though.