I went back again to a previous answer I gave for a study guide question. The question asked about a task queue for thread pool. The question sounded like a general common sense question. Would you grow the queue for new requests, cancel old requests or cancel new requests? I originally thought that I had this one in the bag. But on further looking at it I made the leap to a thought of what does this question want to determine. In a 2003 test there were questions about policy strategies. One part of that question went like this: One strategy for implementing a buffer would be to use a pessimistic baulking strategy. I complained that the term did not exist anywhere. Baulking strategy did but the words together did not. Well it turns out that pessimistic is a class of strategies. It is the opposite of optimistic strategies. I wondered if the current question on thread pool task queue was about that....not the strategy but the area of study. I tend to think that it is. The strategies are not really what is important. The important idea here is to avoid state-dependent actions. The policies you use to do that are like the baulking strategies mentioned. The strategies are like: Inaction, Balking, Guarding, Provisional (pretending until it works), Rollback/Recovery, and retry. The reasons why you want to avoid state dependent actions are: "the client of the object must somehow know enough not to ask the object, in this instance the task queue, to perform actions when it is not in the right state, and/or must be prepared to deal with unannounced failure. Clients must be provided with enough information and control to carry this out." Sometimes you cannot determine this. For instance in the task queue example. Are you ever going to know every way the task queue could ever be used and what programs will be running concurrently in the future to know if the task queue should allocate based on some system state another thread for task execution? This may be user dependent...does the user want some level of performance or some level of throughput in our example. Do you know all users or situations? It is a magic happens here kind of case. So the state conditions become indeterminable. It is better to design a component like a queue that has a fixed number of tasks and reports failure simply because there are no more slots available in the queue. Let the client develop a strategy for handling failure like retry. That way we don`t get into an indeterminable situation like should the task queue grow, shrink or cancel old requests. The later takes policy in to the hands of the queue and takes it out of the hands of the client...making it less flexible.

Anyway, I think I have exhausted the question. My point is that the question is not straight forward. You have to be a mind reader to know what the tester is wanting from you. You may know this information but may not want to use it to effectively argue the question on the test. This kind of question is also context dependent. On a database exam or operating system exam the answer might be different. The sub-context of the question on the software engineering exam is concurrency. Because I don`t answer the question using the principals above is it wrong? I may say everything right, think that I would be right because the question uses the word "you", and still be wrong because it does not follow the grading script probably used to grade this test. Does every grader really expect an answer using the information above? How does this question get answered using opinion and be relevant?

Design inherently has trade-offs. Don`t ask me about design unless your a mind reader client and can take a state-dependent action to understand all the ways I might be used. In software engineering are`t we told in the information above to leave that up to the client...the test giver/grader/tester. Sounds like you might get back an unannounced failure because I am not in the right state. Suck it up and don`t design a candidacy test for failure.