~ubuntu-branches/ubuntu/karmic/firebird2.1/karmic

« back to all changes in this revision

Viewing changes to doc/fb2-todo.txt

  • Committer: Bazaar Package Importer
  • Author(s): Damyan Ivanov
  • Date: 2008-05-26 23:59:25 UTC
  • Revision ID: james.westby@ubuntu.com-20080526235925-2pnqj6nxpppoeaer
Tags: upstream-2.1.0.17798-0.ds2
ImportĀ upstreamĀ versionĀ 2.1.0.17798-0.ds2

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
Firebird 2 architecture
 
2
 
 
3
 
 
4
Engine uses following objects in memory that are a subject
 
5
to threading contention.
 
6
 
 
7
1. Buffer cache
 
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)
 
12
 
 
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.
 
19
 
 
20
3. Lock manager data
 
21
single subsystem mutex. works well now.
 
22
 
 
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.
 
26
 
 
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:
 
31
- no security 
 
32
- no configuration file (set params via special API call)
 
33
- built-in INTL
 
34
- internal UDF handler
 
35
3. Clustered server
 
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.
 
42
 
 
43
Another important thing. Engine AS IS already _is_ already suited for parallel 
 
44
operation by initial design. Versioning is a great thing !
 
45
We NEED:
 
46
- just a few simple Java-like object-level mutexes and a few
 
47
  rw-locks
 
48
- make it run just like CS, but using several shared subsystems
 
49
- we should use constant objects with usage tracking 
 
50
We do NOT NEED:
 
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.
 
57
 
 
58
TODO:
 
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 
 
80
  and company)
 
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.
 
84
 
 
85
Other tasks:
 
86
 
 
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
 
89
 
 
90
Assignments
 
91
 
 
92
Nickolay Samofatov:
 
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.