|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
|
Single-threaded MessageLogger design plan
-----------------------------------------
The key points of change are on either side of the queue:
On the left:
------------
MessageLoggerQ needs to change every time it does b.commit() to a call
to something in the scribe. Clearly, it needs to know whetehter this is single
or multiple threaded to make this choice.
The change is to substitute runCommand(opcode, operand) for the sequence
of creating, filling and committing the buffer for the SingleConsuerQ.
There will be some commands with other slight changes as well.
On the right:
-------------
MessageLoggerScribe::run()
do {
MessageLoggerQ::consume(opcode, operand); // grab next work item from Q
has to become something that gets invoked directly,
and when the break happens, the code needs to return to the
calling routine. The way to do this is to break off the meat
of that internal do loop, into a call to runCommand(opcode, operand).
The remainder of changes on the "right" of the fence are in particulars
of the specific commands.
B) Notify_all() is now not going to be needed in the case of single-threaded.
That implies that the scribe ought to know whether it is single-treaded or
not.
On the fence:
-------------
The issue is that one must not create a separate message logger thread if
single-thread is desired.
We first have to find out which option is wanted: Here, we "parse" the command
line directly, because the setup of the boost parser allows for an exception,
which we want handled by the logger.
We create a SingleThreadMSPresence to substitute for the MessageServicePresence.
That has been tested with the plug-in mechanism, by making it identical to the
service it replaces, and using it against the unit tests. Note that I had to
include the new one in FWCore/MessageService/plugins/Module.cc also.
At this point I have started changing SingleThreadMSPresence but am at a snag:
MessageLoggerQ wants to call MessageLoggerScribe::runCommand, but that would
introduce a dependency of MessageLogger on MessageService.
Resolution of the snag:
When SingleThreadMSPresence is created, it was going to have to instantiate a
MessageLoggerScribe. However, now MessageLoggerScribe puhlicly inherits from
AbstractMessageLoggerScribe, which is defined in the MessageLogger pacakge.
A pointer to that AbstractMessageLoggerScribe, which has a virtual method
runCommand(opcode, operand) is provided to MessageLoggerQ. So now, we
can do scribePointer->runCommand(opcode, operand) an in the implementation
level, it is actually pointing to a true MessageLoggerScribe!
TODO:
SingleThreadMSPresence ctor
OK create the (concrete) MessageLoggerScribe(true)
OK supply the pointer as an AbstractMLscribe to MessageLoggerQ
OK Determine if we need to instantiate MessageLoggerQ early in the
initializer list -- I don't think so, but...
MessageLoggerQ
OK Have place for the mlscribe_ptr
OK Obtain mlscribe_ptr
change commit sequence to mlscribe-ptr->runCommand
change each of the specialized handshake commands (in tandem with MLS)
MessageLoggerScribe
Deal with wind-down issues - may not need code changes, but...
change each of the specialized handshake commands (in tandem with MLQ)
MessageDrop
Inform MessageDrop about singleThread status
When single thread, don't use thread-specific singletons.
Testing
Do we need to pre-instantiate MessageLoggerQ early in the SingleThreadMSPresence
initializer list? No, because before it is ever used, it will be instantiated
by the code trying to use it. There is no worry about interthread coherence
in the single-thread mode.
MessageDrop is also going to have to change, since it is a thread-specific
static. This in turn means it needsto be invformed and so forth.
|