来自单独线程的WCF响应

Question

public interface IEventDismiss
{
    [OperationContract]
    [return:MessageParameter(Name="response")]
    [XmlSerializerFormat]
    Response ProcessRequest(Request request);
}

Hello,

Above is my WCF implementation in C# and it is pretty straight forward. However, it becomes a little more complicated when I receive the request and pass it on to another thread to process to produce the response and finally send this response back.

My algorithm is:

1. Get the request.
2. Pass it on to a separate thread to process by putting onto a static queue for other thread.
3. Once thread finish processing, it put the response object onto a static queue.

4. In my function ProcessRequest I have a while loop that dequeue this response and send it back to the requester.

    public Response ProcessRequest (Request request) { bool sWait = true; Response sRes = new Response(); ResponseProcessor.eventIDQueue.Enqueue(request.EventID); while (sWait) { if (ResponseProcessor.repQ.Count > 0) { sRes = ResponseProcessor.repQ.Dequeue(); sWait = false; } } return sRes; } 

Now, before everyone start to grill me, I am too realized this is bad practice and that's why I ask the question here in hoping to get better way to do this. I realized with the current code I have the following issues:

My while loops maybe in a continue loop and thus eating up the CPU if it has no sleep() in between. My response queue may contains the wrong response back due to the nature of async call.

So I have two questions:

1. Is there a way to put sleep in the while loop to eliminate the high CPU usage?
2. Is there a better way to do this?

Answer 1

There's not point in doing this in the first place. Rather than having the current thread sitting around doing nothing while it waits for another queue to compute the work (while eating up tons of CPU cycles anyway), just compute the response in the current thread and send it back. You are gaining nothing by queuing it for another thread to handle.

You are also using queue objects that cannot be safely accessed from multiple threads, so in addition to being extremely inefficient, it's also subject to race conditions that can mean it won't even work.