Types of Opportunistic Locks

The opportunistic lock operations work with four types of opportunistic locks: level 1, level 2, batch, and filter. Exclusive opportunistic locks are level 1, batch, and filter locks. If a thread has any type of exclusive lock on a file, it cannot also have a level 2 lock on the same file.

Level 1 Opportunistic Locks

A level 1 opportunistic lock on a file allows a client to read ahead in the file and cache both read-ahead and write data from the file locally. As long as the client has sole access to a file, there is no danger to data coherency in providing a level 1 opportunistic lock. The client can request a level 1 opportunistic lock after opening a file. If no other client (or no other thread on the same client) has the file open, the server may grant the opportunistic lock. The client can then cache read and write data from the file locally. If another client has opened the file, then the server refuses the opportunistic lock and the client does no local caching. (The server may refuse the opportunistic lock for other reasons as well, such as not supporting opportunistic locks.) When the server opens a file that already has a level 1 opportunistic lock on it, the server examines the sharing state of the file before it breaks the level 1 opportunistic lock. If the server breaks the lock after this examination, the time the client with the former lock spends flushing its write cache is time the client requesting the file must wait. This time expenditure means that level 1 opportunistic locks should be avoided on files that many clients open. However, because the server checks the sharing state before it breaks the lock, in the case where the server would deny an open request due to a sharing conflict the server does not break the lock. For example, if you have opened a file, denied sharing for write operations, and obtained a level 1 lock, the server denies another client's request to open the file for writing before it even examines your lock on the file. In this instance, your opportunistic lock is not broken. For an example of how a level 1 opportunistic lock works, see Level 1 Opportunistic Lock Example. For more information on breaking opportunistic locks, see Breaking Opportunistic Locks.

Level 2 Opportunistic Locks

A level 2 opportunistic lock informs a client that there are multiple concurrent clients of a file and that none has yet modified it. This lock allows the client to perform read operations and obtain file attributes using cached or read-ahead local information, but the client must send all other requests (such as for write operations) to the server. Your application should use the level 2 opportunistic lock when you expect other applications to write to the file at random or read the file at random or sequentially. A level 2 opportunistic lock is very similar to a filter opportunistic lock. In most situations, your application should use the level 2 opportunistic lock. Only use the filter lock if you do not want open operations for reading to cause sharing-mode violations in the time span between your application's opening the file and receiving the lock. For more information, see Filter Opportunistic Locks and Server Response to Open Requests on Locked Files. For more information on breaking opportunistic locks, see Breaking Opportunistic Locks.

Batch Opportunistic Locks

A batch opportunistic lock manipulates file openings and closings. For example, in the execution of a batch file, the batch file may be opened and closed once for each line of the file. A batch opportunistic lock opens the batch file on the server and keeps it open. As the command processor "opens" and "closes" the batch file, the

network redirector intercepts the open and close commands. All the server receives are the seek and read commands. If the client is also reading ahead, the server receives a particular read request at most one time. When opening a file that already has a batch opportunistic lock, the server checks the sharing state of the file after breaking the lock. This check gives the holder of the lock a chance to complete flushing its cache and to close the file handle. An open operation attempted during the sharing check does not cause the sharing check to fail if the lock holder releases the lock. For an example of how a batch opportunistic lock works, see Batch Opportunistic Lock Example. For more information on breaking opportunistic locks, see Breaking Opportunistic Locks.

Filter Opportunistic Locks

A filter opportunistic lock locks a file so that it cannot be opened for either write or delete access. All clients must be able to share the file. Filter locks allow applications to perform nonintrusive filtering operations on file data (for example, a compiler opening source code or a cataloging program). A filter opportunistic lock differs from a level 2 opportunistic lock in that it allows open operations for reading to occur without sharing-mode violations in the time span between your application's opening the file and receiving the lock. The filter opportunistic lock is the best lock to use when it is important to allow other clients reading access. In other cases, your application should use a level 2 opportunistic lock. A filter opportunistic lock differs from a batch opportunistic lock in that it does not allow multiple openings and closings to be handled by the network redirector the way a batch opportunistic lock does. Your application should request a filter opportunistic lock on a file in three steps: 1. Use the CreateFile function to open a handle to the file with the DesiredAccess parameter set to zero, indicating no access, and the dwShareMode parameter set to the FILE_SHARE_READ flag to allow sharing for reading. The handle obtained at this point is called the locking handle. 2. 3. Request a lock on this handle with the FSCTL_REQUEST_FILTER_OPLOCK control code. When the lock is granted, use CreateFile to open the file again with DesiredAccess set to the GENERIC_READ flag. Set dwShareMode to the FILE_SHARE_READ flag to allow others to read the file while you have it open, the FILE_SHARE_DELETE flag to allow others to mark the file for deletion while you have it open, or both. The handle obtained at this point is called the read handle. Use the read handle to read from or write to the contents of the file. When opening a file that already has a filter opportunistic lock, the server breaks the lock and then checks the sharing state of the file. This check gives the client that held the former opportunistic lock a chance to abandon any cached data and acknowledge the break. An open operation attempted during this sharing check does not cause the sharing check to fail if the former lock holder releases the lock. The file system holds in abeyance the open operation until the lock's owner closes both the read handle and then the locking handle. After this is done, the other client's open request can proceed.

Opportunistic Lock Examples

The following examples show data and SMB message movements as opportunistic locks are made and broken. Note that clients can cache file attribute data as well as file data. Also note that these examples are based on situations where client applications are requesting opportunistic locks from remote servers. These processes are automatically initiated by the network redirector and the remote serverthere is no direct involvement by the client application or applications. The processes described by these examples can be generalized into situations where local client applications are directly requesting

opportunistic locks from the local file system, with the exception that no exchange of data over the network is involved.

Level 1 Opportunistic Lock

The following diagram shows a network-traffic view of a level 1 opportunistic lock on a file. The arrows indicate the direction of data movement, if any.

Event Client X 1 2 3 4 5 6 7 8 9 10 Performs read, write, and other operations ==> Discards read-ahead data Writes data ==> Sends "close" or "done" message ==> Performs read, write, and other operations ==> Opens file, requests level 1 lock ==>

Server

Client Y

<== Grants level 1 opportunistic lock

<== Requests to open file <== Breaks opportunistic lock

Okays open operation ==> <== Performs read, write, and other operations

In event 1, client X opens a file and as part of the open operation requests a level 1 opportunistic lock on the file. In event 2, the server grants the level 1 lock because no other client has the file open. The client proceeds to access the file in the usual manner in event 3. In event 4, client Y attempts to open the file and requests an opportunistic lock. The server sees that client X has the file open. The server ignores Y's request while client X flushes any write data and abandons its read cache for the file. The server forces X to clean up by sending to X an SMB message breaking the opportunistic lock, event 5. Client X "silently" discards any read-ahead data; in other words, this process generates no network traffic. In event 7, client X writes any cached write data to the server. When client X is done writing cached data to the server, client X sends either a "close" or a "done" message to the server, event 8. After the server has been notified that client X is done flushing its write cache to the server or has closed the file, then the server can open the file for client Y, in event 9. Because the server now has two clients with the same file open, it grants an opportunistic lock to neither. Both clients proceed to read from the file, and one or neither writes to the file.

Batch Opportunistic Lock

The following diagram shows a network-traffic view of a batch opportunistic lock. The arrows indicate the direction of data movement, if any.

Event Client X 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Closes file ==> Closes file Closes file Opens file Searches for data Reads data ==> Reads file ==> Opens file, requests batch lock ==>

Server

Client Y

<== Grants batch opportunistic lock

<== Sends data

<== Sends data

<== Opens file <== Breaks opportunistic lock

Okays open operation ==> <== Performs read, write, and other operations

In the batch opportunistic lock, client X opens a file, event 1, and the server grants client X a batch lock in event 2. Client X attempts to read data, event 3, to which the server responds with data, event 4. Event 5 shows the batch opportunistic lock at work. The application on Client X closes the file. However, the network redirector filters out the close operation and does not transmit a close message, thus performing a "silent" close. The network redirector can do this because client X has sole ownership of the file. Later on, in event 6, the application reopens the file. Again, no data flows across the network. As far as the server is concerned, this client has had the file open since event 2. Events 7, 8, and 9 show the usual course of network traffic. In event 10, another silent close occurs. In event 11, client Y attempts to open the file. The server's view of the file is that client X has it open, even though the application on client X has closed it. Therefore, the server sends an a message breaking the opportunistic lock to client X. Client X now sends the close message across the network, event 13. Event 14 follows as the server opens the file for client Y. The application on client X has closed the file, so it does no more transfers to or from the server for that file. Client Y begins data transfers as usual in event 15. Between the time client X is granted the lock on the file in event 2 and the final close at event 13, any file data that the client has cached is valid, in spite of the intervening application open and close operations. However, after the opportunistic lock is broken, cached data cannot be considered valid.

Filter Opportunistic Lock

The following diagram shows a network-traffic view of a filter opportunistic lock. The arrows indicate the direction of data movement, if any.

Event 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Client X Opens file with no access rights ==>

Server

Client Y

<== Opens the file Requests filter lock==> <== Grants lock Opens file for reading ==> <== Reopens the file Reads data using the read handle ==> <== Sends data <== Sends data <== Sends data <== Opens the file Opens the file ==> <== Requests filter lock Denies filter lock==> <== Reads data Sends data ==> Reads (cached) data Closes file ==> <== Closes file

In the filter opportunistic lock, client X opens a file, event 1, and the server responds in event 2. The client then requests a filter opportunistic lock in event 3, followed by the server granting the opportunistic lock in event 4. Client X then opens the file again for reading in event 5, to which the server responds in event 6. The client then attempts to read data, to which the server responds with data, event 8. Event 9 shows the filter opportunistic lock at work. The server reads ahead of the client and sends the data over the network even though the client has not requested it. The client caches the data. In event 10, the server also anticipates a future request for data and sends another portion of the file for the client to cache. In event 11 and 12, another client, Y, opens the file. Client Y also requests a filter opportunistic lock. In event 14, the server denies it. In event 15, client Y requests data, which the server sends in event 16. None of this affects client X. At any time, another client can open this file for read access. No other client affects client X's filter lock. Event 17 shows client X reading data. However, because the server has already sent the data and the client has cached it, no traffic crosses the network. In this example, client X never tries to read all the data in the file, so the read-ahead indicated by events 9 and 10 is "wasted"; that is, the data is never actually used. This is an acceptable loss because the read-ahead has sped up the application. In event 18, client X closes the file. The client's network redirector abandons the cached data. The server closes the file.