1
Firebird 2 architecture
4
Engine uses following objects in memory that are a subject
5
to threading contention.
8
Protection: single mutex on buffer cache object.
9
All modification to buffers should be performed in this module only
10
and under mutex. Only costant pointers should be given out
11
(it should be working this way now - make interface declaration appropriate)
13
2. Metadata cache. Compiled requests + request cache
14
Idea of implementation: only constant objects should be stored in cache.
15
Use single cache-level mutex to protect addition to cache and removal from
16
cache. Modify objects only when they are outside of cache. Derive all cached
17
objects (including requests and relations) from unified cacheable object
18
which will allow to track object usage.
21
single subsystem mutex. works well now.
23
4. Cached database header data (DBB) and other cached pieces of data.
24
Protect it with a single dbb-level mutex to avoid deadlocks.
25
Use temporary structures when needed to cache snapshots of this data.
27
Targets we are going to support under Firebird 2 architecture
28
1. Multi-threaded engine. Just like SuperServer, but SMP-friendly.
29
2. Embeeded server. The same as multi-threaded but is packaged in a single
30
.dll/.so module. Other differences:
32
- no configuration file (set params via special API call)
34
- internal UDF handler
36
Run multi-process engine on each cluster node. Direct page latches and
37
other locks to a distributed lock manager. Processes may share the same
38
buffer and metadata cache via shared memory. This target should be kept
39
in mind, but may not be finalized in 2.0 release. Making Firebird run
40
in such configuration is quite an easy thing (at least without shared
41
cache), but it requires expensive equipment and time for testing.
43
Another important thing. Engine AS IS already _is_ already suited for parallel
44
operation by initial design. Versioning is a great thing !
46
- just a few simple Java-like object-level mutexes and a few
48
- make it run just like CS, but using several shared subsystems
49
- we should use constant objects with usage tracking
51
- big amount of mutexes and mutex arrays
52
- relation-level mutexes and other shit like this
53
Mutexes should be aquired only for a very short periods of time.
54
Linked lists usage should be discouraged. All classes touched
55
by thread-safety cleanup (bdb, att, dbb) should be fixed to avoid
56
LLS usage as it is usually thread-unsafe.
59
1. Implement locking objects.
60
2. Implement thread-safe, SMP-friendly memory manager.
61
3. Review every source module inside the engine regarding its MT-safety.
62
TODO-list might extend after this point, but not too much because we
63
already have SMP-friendly CS builds.
64
4. Fix up buffer cache to make it thread-safe,
65
and solve its performance problems.
66
5. Re-write metadata cache
67
6. Make JRD requests use new metadata cache
68
7. Make DSQL compilation thread-safe (via porting it to BISON correctly)
69
8. Make DSQL requests use new metadata cache
70
9. Implement cache of compiled requests (should be easy at this point)
71
10. Thread context should be converted to a class and removed from
72
parameters from all functions (and SET_TDBB should be eliminated too).
73
tdbb_default memory pool usage should be eradicated. Functions should
74
normally derive their context from parameters, not from thread context.
75
Final goal is to minimize or even eliminate TLS usage at all (because
76
its usage is simular to local variables usage in terms of maintainability).
77
11. Warp dbb/att access with thread-safe accessor methods using dbb-level mutex.
78
Review all places where it is used.
79
12. Kill manual thread shcheduling (sch.cpp, THREAD_ENTER/THREAD_EXIT
81
13. Engine should be thread-safe at this point. TEST IT !
82
Perform stress testing and add needed logging where required.
83
We need to unify debug logging across the engine.
87
1. NOMEM cleanup + EH cleanup. Use auto_ptr-like templates for resource management
88
2. system_call_failed exception must have call name, parameters and error code
93
Points 1 and 2 are almost finished in my tree. Locking objects need some more
94
comparative testing. Hardware memory pages manager (1.5 uses malloc for this
95
purpose) is neary finished and needs testing.