Re: Re[2]: Fw: [Firebird-devel] IB/FB Lock manager failures

[John B. <bel...@cs...>]

Hi,

On Wednesday, September 18, 2002, at 11:11 AM, Nickolay Samofatov wrote:

> Hello firebird-devel-admin,
>
> Wednesday, September 18, 2002, 9:20:50 PM, you wrote:
>
>>         I'll start by addressing the lock manager issue.  While 
>> reading all
>> the posts it occurred to me that there are many competing goals and
>> requirements for the lock manager.  For example, the performance goal
>> might not be well meet by the current file based implementation, but
>
> [trimmed]
>
>> Hmm, I'm sure I've forgot some things, and have some stuff just plain
>> wrong here.  But I wanted to get the discussion going :-)
>
>
>> -John
>
> I agree with our goal and general idea. But you missed one issue:
>
> If we start from CS codebase we will always have threading-stable
> version. Fine-grained locking is not a requirement for
> SMT.

You are correct - it isn't a requirement.  But it is necessary (to an 
extent) to avoid massive duplication of effort and wasted resources.

> We can just copy almost all global data to thread
> context in the beginning.

There are a number of issues left out of the "almost all" category:
will each thread have its own caches (page, metadata, etc, etc, etc...)?
will each thread have its own lock manager?
will each thread load its own loadable modules?  Is that acceptable on 
all supported platforms?
how will we deal with inter thread signaling? (OS support is still 
shoddy on a number of systems)
what is responsible for creating the context?
where does the y-valve fit in?

> No locks required. And than evaluate
> the code making some structures shared. We will always have
> threading-stable version during entire process.

Which reminds me, we need to decide if FB is going to support multiple 
threads in a single connection.  If the answer is "yes" then that 
dictates some of the structures that need to be shared.

> If we instead
> try to share much (like SS does) in the beginning we'll end up
> with unstable version for a long period of time.

This approach would trade short term memory usage and speed for 
stability and testability.  Although I'm not sure that we couldn't come 
up with a transition plan for SS as well.

> I don't think it is
> acceptable in Open-Source development. Installed base, users
> should help us to fix bugs and improve the code.

It is important to have a working product that users can test.  I don't 
think anyone wants to decommission FB for a year or more while the 
changes are made.

>
> [...]

-John