Hand to hand western style is 1:1 blocking I/O, both the payer and recipient must be simultaneously active at the same moment.
At a restaurant/bar this tray is the worlds smallest FIFO and you put a packet into the packet buffer at your convenience and the service worker clears the buffer at their convenience, and this protocol is considered so polite that even at convenience stores when you're in a line you still use the FIFO buffer and pretend you're both not in a hurry and have plenty of time for proper, measured, unhurried service, even when you don't actually have the time. Its impolite to force a two concurrent processes to deadlock waiting a simple packet buffer transfer, and even if they do, they like to pretend its not happening.
If the trays looked nicer it would have been an obvious conspicuous consumption opportunity. The cheap store has injection molded plastic; we have marble trays; they have antique engraved ebony.
I wonder how or if they handle what CS would call transaction locks, to make sure the other process doesn't grab the buffer to empty it while the filler is still shoveling in small change. Not having been to Japan yet, I'm guessing the tray moves and at least subtly you somehow indicate you're done filling the bucket before the service worker starts emptying it.
I had another model based on traditional innumeracy, if traditionally payers were innumerate you shovel coins onto the bucket until the service worker sees enough and takes away the bucket. I find this model theoretically possible to implement although highly unlikely in practice.
I love to stretch... good for the brain. Its a concurrency design pattern, never, never ever, create an opportunity for complicated deadlocks at the protocol or implementation layer when you can just toss down a boring simple well understood and easy to debug FIFO/buffer. There are times and places where complication is needed in programming, but paying your sushi bill isn't it. Or the meta design pattern of always make it as simple as possible and not a bit too simple.
Even if this is total space cadet time, I like thinking about concurrency issues. (edited to fix horrible phrasing: I like to look at Japanese currency trays thru concurrency tinted sunglasses, just because its fun, even if the Japanese themselves don't like those sunglasses, also its funny to talk about currency and concurrency at the same time)
Hand to hand western style is 1:1 blocking I/O, both the payer and recipient must be simultaneously active at the same moment.
At a restaurant/bar this tray is the worlds smallest FIFO and you put a packet into the packet buffer at your convenience and the service worker clears the buffer at their convenience, and this protocol is considered so polite that even at convenience stores when you're in a line you still use the FIFO buffer and pretend you're both not in a hurry and have plenty of time for proper, measured, unhurried service, even when you don't actually have the time. Its impolite to force a two concurrent processes to deadlock waiting a simple packet buffer transfer, and even if they do, they like to pretend its not happening.
If the trays looked nicer it would have been an obvious conspicuous consumption opportunity. The cheap store has injection molded plastic; we have marble trays; they have antique engraved ebony.
I wonder how or if they handle what CS would call transaction locks, to make sure the other process doesn't grab the buffer to empty it while the filler is still shoveling in small change. Not having been to Japan yet, I'm guessing the tray moves and at least subtly you somehow indicate you're done filling the bucket before the service worker starts emptying it.
I had another model based on traditional innumeracy, if traditionally payers were innumerate you shovel coins onto the bucket until the service worker sees enough and takes away the bucket. I find this model theoretically possible to implement although highly unlikely in practice.