\nThere are multiple ways of viewing the interaction between\nposted messages and input messages.\nMSDN prefers to view posted messages and input messages as\npart of one giant pool of messages in a message queue<\/I>,\nwith rules about which ones get processed first.\nI, on the other hand, prefer to think of posted messages and\ninput messages as residing in different queues that are\nprocessed in sequence.\n<\/P>\n
\nBy analogy, consider a business with a policy that\nloyalty program members are served ahead of\nregular customers.\n<\/P>\n
\nOne way of organizing this is to form a single queue,\nbut sorting them so members go to the front.\nTo call the next person in line, you just take whoever\nis at the head of the queue.\n<\/P>\n
\nAddToQueue(Customer c)\n{\n if (c is a member and the queue contains non-members) {\n let n = the first non-member in the queue;\n insert c in front of n;\n } else {\n insert c at the end of the queue;\n }\n}<\/p>\nGetNextCustomer()\n{\n if (there is somebody in the queue) {\n return the first person in the queue;\n }\n \/\/ nobody is waiting\n return null;\n}\n<\/PRE>\n
\nThis approach works fine from a programmatic standpoint,\nbut people might not like it when they see others cutting\nin front of them.\nYou might therefore choose to create two queues,\none for members and one for non-members:\n<\/P>\n
\nAddToQueue(Customer c)\n{\n if (c is a member) {\n insert c at end of member queue;\n } else {\n insert c at end of non-member queue;\n}<\/p>\nGetNextCustomerInLine()\n{\n if (there is somebody in the member queue) {\n return the first person in the member queue;\n }\n if (there is somebody in the non-member queue) {\n return the first person in the non-member queue;\n }\n \/\/ nobody is waiting\n return null;\n}\n<\/PRE>\n
\nNote that this second algorithm serves customers in exactly\nthe same order; the only difference is psychological.\nCustomers might resent the presence of a members<\/I> line\nsince it reminds them that other people are getting\nspecial treatment.\nOr this algorithm may not be practical because\nyou don’t have room in your lobby for two lines.\nYou might choose yet another algorithm,\nwhere you select members\nat the time the customers\nare served rather than when they arrive.\nEverybody forms a single queue, but sometimes\na customer in the middle of the queue gets pulled out\nfor special treatment.\n(Maybe they wear red hats so they are easy to spot.)\n<\/P>\n\nAddToQueue(Customer c)\n{\n insert c at end of queue;\n}<\/p>\nGetNextCustomerInLine()\n{\n if (there is a member in the queue) {\n return the first member in the queue;\n }\n \/\/ else only non-members remaining\n if (there is somebody in the queue) {\n return the first person in the queue;\n }\n \/\/ nobody is waiting\n return null;\n}\n<\/PRE>\n
\n(Some banks use a variant of this algorithm\nto\n\nseparate potential bank-robbers from the rest of the customers<\/A>.)\n<\/P>\n\nFrom the standpoint of determining\nwho gets served in what order,\nall of these algorithms are equivalent.\nOne may be more efficient,\none may be easier to understand,\none may be easier to maintain,\none may be easier to debug,\nbut they all accomplish the same thing.\n<\/P>\n
\nSo go ahead and use whatever interpretation of the message queue you like.\nThey are all equivalent.\n<\/P>\n
\nBut the interpretation that I use is the one I presented\n\nseveral years ago at the PDC<\/A>,\nwhere the posted message queue and input queues are\nconsidered separate queues.\nI prefer that interpretation because it makes input queue attachment\neasier to understand.\n<\/P>\n\nIn the analogy above, I prefer viewing things in terms of the\nsecond algorithm, with separate queues;\nMSDN prefers viewing things in terms of the third algorithm,\nwith a single queue, but with some messages given preferential\ntreatment over others.\n<\/P>\n