]> git.saurik.com Git - apple/xnu.git/blob - osfmk/man/MO_lock_completed.html
xnu-344.49.tar.gz
[apple/xnu.git] / osfmk / man / MO_lock_completed.html
1 <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>.