Named query caching is a distinct layer from the 'Cache & Share' option available in some Perspective binding types.
Named query caching works by keying off the named query path plus parameters, with a fixed expiration time.
So, let's have sessions A and B.
Both have a query binding, not cache & share, set to run a named query with a cache time of 5 seconds.
If A issues a query, and it returns a value, then within the next five seconds any identical query (including all parameter values) issued by B will hit the cache and not require any database interaction.
If A issues a query, and before it returns, B issues the same query - the underlying query will be executed twice. The second query will not 'wait' for the cache to be built.
If A issues a query, and it returns a value, then B issues a query after five seconds, B issues a new query and builds a new cache entry that will then expire after five seconds.
Now, the 'cache and share' value cache mechanism works on fundamentally the same principle, but at a different layer, because it's an agnostic mechanism that's used internally in various Perspective components as well as exposed via bindings.
The basic principle is the same, but the implementation works somewhat differently:
If A runs a binding and it returns a value, then within the poll rate of the binding, B runs the same binding, B will get the cached value.
If A runs a binding, and, before it has returned, B runs the same binding, B will 'wait' on the same task to return a result - no duplicate work.
If A runs a binding and after it's expired, B runs the same binding, B will run a new task and cache a new result.
Finally, the interaction between 'cache and share' and 'named query caching' - named query execution is a task that the cache and share system can execute. So even if the cache & share evaluation attempts to run a task twice, it could still hit the named query cache and return a cached result immediately.