Subject RE: [IB-Architect] Processes, Threads, and Synchronization
Author Skopalik Slavomir
> The strategic question is the scope of a lock. Current Interbase/Firebird
> has a single mutex for the entire engine. It could be reduced to a
> mutex on the memory manager (see previous reference to "hoard"), another
> on the meta-data, another on the cache manager etc. This would allow
> more parallelism. But changing the locking from "meta-data" to
> individual tables would give more at a cost of more difficult
> analysis (deadlock avoidable) and programming. Netfrastructure
> pushes the granuality as low as possible, but requires a locking
> scheme where uncontested shared access can be granted essentially
> for free.

Why can't be used instancing of curent version SS ?
Each instance (as process or internal set of threads) for each database.
It is can use more avaliable resources on single and multiple
CPU system when more database connected at same time.