Subject | RE: [IB-Architect] Re: Events Improvement |
---|---|
Author | Jim Starkey |
Post date | 2001-05-08T18:13:51Z |
At 09:42 AM 5/8/01 +0400, Dmitry Yemanov wrote:
code complete with data structures, page buffers, a lock manager,
and an event manager (on VMS all processes must be on the the
cluster containing the database file; on other OSes they must be
on the same CPU). All interprocess synchronization takes place
through the lock and event managers. On VMS, Firebird uses
the VMS lock manager for both locks and events. On other
operating systems Firebird uses whatever shared memory and
synchronization primitives available. For the rest of this
discussion (and maybe the rest of our lives) we'll ignore VMS.
Because the lock and event tables are shared among processes,
it is likely (i.e. certain) that they will be mapped at different
addresses. This leads to three ironclad rules:
1. Every involved with the lock or event manager must be in
the shared region, and
2. All points must be relative and translated to absolute
addresses on reference.
3. Appropriate OS synchronization primitives must be used
to control access to the shared memory region.
I think the implications are fairly clear from this point on.
Jim Starkey
>In the classic architecture, each process contains the full engine
>> I need to think about the other details before I comment
>> further, but allocating the APE out of heap rather than the
>> shared region will definitely break the event manager on
>> classic.
>
>Bad news. I was afraid of something like this. But unfortunately I'm not
>very familiar with Classic, so could you comment this issue more
>particularly? I would very much like to have the whole picture in my head.
>
code complete with data structures, page buffers, a lock manager,
and an event manager (on VMS all processes must be on the the
cluster containing the database file; on other OSes they must be
on the same CPU). All interprocess synchronization takes place
through the lock and event managers. On VMS, Firebird uses
the VMS lock manager for both locks and events. On other
operating systems Firebird uses whatever shared memory and
synchronization primitives available. For the rest of this
discussion (and maybe the rest of our lives) we'll ignore VMS.
Because the lock and event tables are shared among processes,
it is likely (i.e. certain) that they will be mapped at different
addresses. This leads to three ironclad rules:
1. Every involved with the lock or event manager must be in
the shared region, and
2. All points must be relative and translated to absolute
addresses on reference.
3. Appropriate OS synchronization primitives must be used
to control access to the shared memory region.
I think the implications are fairly clear from this point on.
Jim Starkey