|RE: [IB-Architect] Processes, Threads, and Synchronization
> The strategic question is the scope of a lock. Current Interbase/FirebirdWhy can't be used instancing of curent version SS ?
> 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.
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.