Phil Henshaw wrote: > So a bus, in functional terms, is a 'resource' that never runs into limits > of the kind where users are forced to learn about each other's complex needs > in order to figure our how to get the last little drop of capacity out? > That is, leaving aside the transformational 'synergy' of having everyone in > line fall in love and forget about their shopping... among the other kinds > of choices I had in mind. :-) > A bus is a potential bottleneck. Typically a bus runs a slower rate than a processor. Similarly the things connected to the bus and the memory are also slower. So there's a fast resource that can be divided up in a more sensible way. Imagine a super-fast Mighty Mouse clerk, that runs from station to station, operating a hundred times the speed of a typical customer,. Such a clerk could soak up all of the latency introduced by the users of the customer and various sorts of exceptional conditions. That's basically analogous to massive hyperthreading on a computer.
You might be thinking of ways to defeat these grocery store queues. For example, what happens when 10 customers come along each with 50 Costco flatbed carts and block all of the lines (supposing there are 10 lines)? Then everyone else has to wait. That can be fixed if the clerks can quickly push off all of a customer's purchases to the side and start a new checkout on their register. That 's what virtualization software/hardware does, or at a higher level, or system-level checkpointing. In these everyday cases, I can't see how it makes any sense to model other users. The system architecture should be able to cope. Anyway, the latter is an example where there can be the perception there is a limited resource, but really there is not. Users may not be able to make good use of peak speed anyway, e.g. having Mighty Mouse as their individual clerk. Marcus ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
