blob: ec38687b433d0eaaaa442987573f425e27cc1b6a (
plain)
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
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
|
<html>
<head>
<title>Apache Qpid : CppEventChannelIo</title>
<link rel="stylesheet" href="styles/site.css" type="text/css" />
<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
<tr>
<td valign="top" class="pagebody">
<div class="pageheader">
<span class="pagetitle">
Apache Qpid : CppEventChannelIo
</span>
</div>
<div class="pagesubheading">
This page last changed on Nov 06, 2006 by <font color="#0050B2">aconway</font>.
</div>
<h1><a name="CppEventChannelIo-EventchannelIOabstraction."></a>Event channel IO abstraction.</h1>
<p>Goals: provide an IO abstraction layer that can be efficiently implemented using differente techniques:</p>
<ul>
<li>select/poll/epoll</li>
<li>aio_</li>
<li>ec_ new linux event channel.</li>
<li>shared mem, IPC etc.</li>
</ul>
<p>The event channel is the central IO absctraction.</p>
<p>Async requests are posted to the channel as Events. When the request is complete it is returned from getEvent() with the data filled in.</p>
<p>We provide synchronous APIs to wrap post(event), wait for getEvent(). On posix these APIs are actually implemented using user-level context swithching so we get a simple programing model with minimal blocking and kernel context switching.</p>
<p>Note: this means that code before and after an apparently synchronous call ''may execute in different threads''. Don't use thread-local<br/>
storage. The term "task" will denote the user-level execution context and we'll provide "task-locak storage" that is carried with the user<br/>
context if we need it. </p>
<p>We can provide some simple in-process synchronization via the event channel to allow use level tasks to block on application events.</p>
<h2><a name="CppEventChannelIo-Coreconcepts%3A"></a>Core concepts:</h2>
<p><tt>EventChannel</tt>:</p>
<ul>
<li>Manages thread pool.</li>
</ul>
<ul>
<li>Worker threads loop getting and processing events.</li>
</ul>
<ul>
<li>Async requests: post request event, it will be processed when complete.</li>
</ul>
<ul>
<li>Notification: Threads can block on a notification event to be woken when some other thread posts that event.</li>
</ul>
<p><tt>Task</tt>:</p>
<ul>
<li>like lightweight thread</li>
</ul>
<ul>
<li>ucontext APIs for user-level context switch.</li>
</ul>
<p>Linux ec_ + ucontext implementation:</p>
<ul>
<li>EventChannel is thin facade over native ec_ APIs.</li>
</ul>
<ul>
<li>Tasks are scheduled onto threads.</li>
</ul>
<ul>
<li>ideally our threads ''never block'' (but they can be preempted)</li>
</ul>
<ul>
<li>when a thread hits a blocking point it suspends the current task and swaps to a ready task.</li>
</ul>
<ul>
<li>when the suspended task is unblocked (e.g. async IO completes) it becomes ready and will be picked up by another thread.</li>
</ul>
<p>Linux epoll + ucontext:</p>
<ul>
<li>Prove ucontext ideas.</li>
</ul>
<ul>
<li>Use traditional polling inside EventChannel.</li>
</ul>
<p>APR portable impl: only need client support - simple blocking socket calls.</p>
<p>Computing thread pool size:</p>
<ul>
<li>Initial size based on availabe CPU paralleism</li>
</ul>
<ul>
<li>On linux /proc/cpuinfo? Any portable options.</li>
</ul>
<ul>
<li>Thread pool grows automatically to avoid deadlock.</li>
</ul>
<p><tt>ThreadPool</tt>: Size should stay close to actuall hardware paralellism + some delta due to pre-empted threads and thread-blocking<br/>
synchronization calls required in the event channel implementation itself.</p>
<p>Questions:</p>
<ul>
<li>Does the thread pool need to shrink to reclaim resources?</li>
</ul>
<ul>
<li>Is there a risk of unbounded growth? How to avoid without deadlock?</li>
</ul>
</td>
</tr>
</table>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td height="12" background="border/border_bottom.gif"><img src="border/spacer.gif" width="1" height="1" border="0"/></td>
</tr>
<tr>
<td align="center"><font color="grey">Document generated by Confluence on Apr 22, 2008 02:47</font></td>
</tr>
</table>
</body>
</html>
|
