Lines Matching refs:thread
31 A thread that sends a message is known as the **sending thread**,
32 while a thread that receives the message is known as the **receiving thread**.
33 Each message may be received by only one thread (i.e. point-to-multipoint and
38 (and even specify) the identity of the other thread.
45 Both the sending thread and the receiving thread supply a message descriptor
55 A **message buffer** is an area of memory provided by the thread that sends or
69 it is given to a mailbox by the sending thread. The message is then owned
70 by the mailbox until it is given to a receiving thread. The receiving thread
78 A sending thread can specify the address of the thread to which the message
79 is sent, or send it to any thread by specifying :c:macro:`K_ANY`.
80 Likewise, a receiving thread can specify the address of the thread from which
81 it wishes to receive a message, or it can receive a message from any thread
83 A message is exchanged only when the requirements of both the sending thread
84 and receiving thread are satisfied; such threads are said to be **compatible**.
86 For example, if thread A sends a message to thread B (and only thread B)
87 it will be received by thread B if thread B tries to receive a message
88 from thread A or if thread B tries to receive from any thread.
89 The exchange will not occur if thread B tries to receive a message
90 from thread C. The message can never be received by thread C,
91 even if it tries to receive a message from thread A (or from any thread).
97 In a synchronous exchange, the sending thread blocks until the message
98 has been fully processed by the receiving thread. In an asynchronous exchange,
99 the sending thread does not wait until the message has been received
100 by another thread before continuing; this allows the sending thread to do
102 *before* the message is given to a receiving thread and fully processed.
104 by the sending thread.
107 preventing a sending thread from generating messages faster than they can be
109 explicit form of flow control, which allows a sending thread to determine
160 A pointer to the sending thread's message buffer. Set it to ``NULL``
165 The address of the desired receiving thread. Set it to :c:macro:`K_ANY`
166 to allow any thread to receive the message. Leave this field uninitialized
171 The address of the desired sending thread. Set it to :c:macro:`K_ANY`
172 to receive a message sent by any thread. Leave this field uninitialized
180 A thread sends a message by first creating its message data, if any.
182 Next, the sending thread creates a message descriptor that characterizes
185 Finally, the sending thread calls a mailbox send API to initiate the
187 thread, if one is currently waiting. Otherwise, the message is added
192 of the sending thread. Messages of equal priority are sorted so that
196 receiving thread has both received the message and retrieved the message data.
198 sending thread is reached, the message is removed from the mailbox's send queue
200 the sending thread can examine the message descriptor to determine
201 which thread received the message, how much data was exchanged,
202 and the application-defined info value supplied by the receiving thread.
205 A synchronous send operation may block the sending thread indefinitely,
206 even when the thread specifies a maximum waiting period.
208 before the message is received by another thread. Once a message is received
209 there is *no* limit to the time the receiving thread may take to retrieve
210 the message data and unblock the sending thread.
213 This allows the sending thread to continue processing regardless of whether the
214 message is given to a receiving thread immediately or added to the send queue.
215 The sending thread may optionally specify a semaphore that the mailbox gives
217 has been received and its data retrieved by a receiving thread.
218 The use of a semaphore allows the sending thread to easily implement
220 an application-specified number of messages from a sending thread
224 A thread that sends a message asynchronously has no way to determine
225 which thread received the message, how much data was exchanged, or the
226 application-defined info value supplied by the receiving thread.
232 to any consuming thread that wants one. The message "info" field is
262 from a producing thread to any consuming thread that wants it.
264 the maximum size message buffer that each thread can handle.
304 A thread receives a message by first creating a message descriptor that
307 from the first compatible thread it finds. If no compatible thread exists,
308 the receiving thread may choose to wait for one. If no compatible thread
309 appears before the waiting period specified by the receiving thread is reached,
311 Once a receive operation completes successfully the receiving thread
312 can examine the message descriptor to determine which thread sent the message,
314 and the application-defined info value supplied by the sending thread.
323 (FIFO) order, due to the thread compatibility constraints specified by the
324 message descriptors. For example, if thread A waits to receive a message
325 only from thread X and then thread B waits to receive a message from
326 thread Y, an incoming message from thread Y to any thread will be given
327 to thread B and thread A will continue to wait.
329 The receiving thread controls both the quantity of data it retrieves from an
330 incoming message and where the data ends up. The thread may choose to take
332 or to take no data at all. Similarly, the thread may choose to have the data
335 The following sections outline various approaches a receiving thread may use
341 The most straightforward way for a thread to retrieve message data is to
342 specify a message buffer when the message is received. The thread indicates
350 left unchanged. In all cases the mailbox updates the receiving thread's
357 producing thread, using the immediate data retrieval technique. The message
359 message buffer that each thread can handle.
399 A receiving thread may choose to defer message data retrieval at the time
402 The thread does this by specifying a message buffer location of ``NULL``
407 However, the mailbox still updates the receiving thread's message descriptor
410 The receiving thread must then respond as follows:
413 contained no data or the receiving thread did not want to receive any data.
414 The receiving thread does not need to take any further action, since
417 * If the message descriptor size is non-zero and the receiving thread still
418 wants to retrieve the data, the thread must call :c:func:`k_mbox_data_get`
422 * If the message descriptor size is non-zero and the receiving thread does *not*
423 want to retrieve the data, the thread must call :c:func:`k_mbox_data_get`
429 used when memory limitations make it impractical for the receiving thread to
434 to get message data from a producing thread only if the message meets