xnu-1504.3.12.tar.gz

[apple/xnu.git] / osfmk / man / MO_lock_completed.html

<h2>memory_object_lock_completed</h2>
<hr>
<p>
<strong>Server Interface</strong> - Report to memory manager that a previous consistency control request has been handled.
<h3>SYNOPSIS</h3>
<pre>
<strong>kern_return_t   memory_object_lock_completed</strong>
                <strong>(memory_object_t</strong>                     <var>reply_port</var>,
                 <strong>memory_object_control_t</strong>         <var>memory_control</var>,
                 <strong>vm_offset_t</strong>                             <var>offset</var>,
                 <strong>vm_size_t</strong>                               <var>length</var><strong>);</strong>


<strong>kern_return_t   seqnos_memory_object_lock_completed</strong>
                <strong>(memory_object_t</strong>                     <var>reply_port</var>,
                 <strong>mach_port_seqno_t</strong>                        <var>seqno</var>,
                 <strong>memory_object_control_t</strong>         <var>memory_control</var>,
                 <strong>vm_offset_t</strong>                             <var>offset</var>,
                 <strong>vm_size_t</strong>                               <var>length</var><strong>);</strong>
</pre>
<h3>PARAMETERS</h3>
<dl>
<p>
<dt> <var>reply_port</var> 
<dd>
[in reply (receive) right]
The port supplied in the corresponding
<strong>memory_object_lock_request</strong> call.
<p>
<dt> <var>seqno</var> 
<dd>
[in scalar]
The sequence number of this message relative to the port 
named in the <strong>memory_object_lock_completed</strong> message.
<p>
<dt> <var>memory_control</var> 
<dd>
[in memory-cache-control send right]
The memory cache control port 
to be used for a response by the memory manager.  If the memory
object has been supplied to more than one kernel, this parameter
identifies the kernel that is making the call.
<p>
<dt> <var>offset</var> 
<dd>
[in scalar]
The offset within the memory object.
<p>
<dt> <var>length</var> 
<dd>
[in scalar]
The number of bytes to which the call refers, starting at
<var>offset</var>.  The number converts to an integral number of memory object
pages.
</dl>
<h3>DESCRIPTION</h3>
<p>
A <strong>memory_object_lock_completed</strong> function is called as
the result of a kernel 
message confirming the kernel's action in response to a
<strong>memory_object_lock_request</strong> call from the memory manager.  
The memory manager can use the <strong>memory_object_lock_request</strong> call to:
<ul>
<li>
Alter access restrictions specified in the <strong>memory_object_data_supply</strong>
call or a previous <strong>memory_object_lock_request</strong> call.
<p>
<li>
Write back modifications made in memory.
<p>
<li>
Invalidate its cached data.
</ul>
<p>
When the kernel completes the requested actions, it calls
<strong>memory_object_lock_completed</strong> (asynchronously) using
the port explicitly provided in the 
<strong>memory_object_lock_request</strong> call.  Because the memory manager cannot 
know which pages have been modified, or even which pages remain in the 
cache, it cannot know how many pages will be written back in response to a 
<strong>memory_object_lock_request</strong> call.  Receiving the
<strong>memory_object_lock_completed</strong> call is the only sure
means of detecting completion.  The completion call 
includes the offset and length values from the consistency request
to distinguish 
it from other consistency requests.
<h3>RETURN VALUES</h3>
<p>
Only generic errors apply.
<h3>RELATED INFORMATION</h3>
<p>
Functions:
<a href="memory_object_lock_request.html"><strong>memory_object_lock_request</strong></a>,
<a href="memory_object_server.html"><strong>memory_object_server</strong></a>,
<a href="SMO_server.html"><strong>seqnos_memory_object_server</strong></a>.