Title:

tryGetLock() - attempt to acquire a lock on the threadLock object and return even if unsuccessful. This is a non-blocking form of getLock that is guaranteed to return "immediately". If a condition is supplied, the call waits until the lock is required and the condition is evaluated once within the lock. Whatever the result of the evaluation, the call returns with the lock held.

Usage:

tryGetLock(threadlock, condition, safe=F)

Arguments:

threadlock:

the threadLock object for which the lock is sought.

condition:

if this argument is supplied, the condition is evaluated within the lock (when acquired) and while the condition evaluates to F the lock is released and the thread waits to be notified by other threads of a change in the variables associated with this expression. When the condition evaluates to T, the call returns and the lock is held.

The purpose of this is to test the values of variables which are shared across threads. The test must be protected to ensure no thread modifies the variables during the evaluation of the expression and also that the variables have consistent values.

This is different from Pthreads in which the thread must explicitly call pthread_mutex_lock() and pthread_mutex_unlock() and have a call to pthread_cond_wait() inside the lock. So code here is asymmetric.

safe:

if T, the evaluation manager is queried to determine if the calling thread already holds the lock. If so, the function returns. This is for novice users or in the case of extreme bugs. If the calling thread already holds the lock, it is highly probable that the collection of threads has been misdesigned. This argument merely prevents deadlock.

Side Effect:

This thread attempts to acquire the lock associated with threadlock. If the lock is held by another thread, F is returned. Otherwise, if the lock is acquired or safe = T and this thread already holds the lock T is returned. This is a non-blocking test to acquire the lock. It might be used in the same circumstances in which non-blocking I/O is used in non-threaded applications. However, since we can have multiple threads, it is often more appropriate to have one thread call getLock() and a second thread perform other actions that would have been performed in a single thread if the lock couldn't be acquired immediately. This is often used in optimizing performance where it can be beneficial to recreate data if another thread currently has exclusive access to it. For instance, imagine we have a cache of file/URL contents or images as in a browser. Suppose one thread is performing some modifications to an object that is needed by another thread. If the operation is lengthy relative to the time it takes to obtain a new version of the object (e.g. across the net) then the second thread may attempt to acquire the lock in a non-blocking manner and fail. In this case, it can retrieve the object directly and keep a local copy. Of course, if the second thread requires the modified version of the object that results from the first threads operation, this is not useful. Indeed, more frequently than not, situations in which a non-blocking lock is used can be simplified using a different organizational approach.

The tryGetLock() function can be used to spin in cases where spinning (and polling) is more efficient than being notified of a release of the lock!

See Also:

getLock()

threadLock

threadLock()

Examples:

Key Words:

User Level Threads