Nuke binary plugins 14.1.5
 
Loading...
Searching...
No Matches
DD::Image::Lock Class Reference
Inheritance diagram for DD::Image::Lock:
DD::Image::RecursiveLock DD::Image::SignalLock

Public Member Functions

 Lock ()
 
pthread_mutex_t & get_mutex ()
 
void lock ()
 
void spinlock ()
 
void unlock ()
 
bool trylock ()
 
void spinsignal ()
 
void spinwait ()
 
virtual ~Lock ()
 

Protected Member Functions

 Lock (const pthread_mutexattr_t *a)
 

Friends

class SignalLock
 

Detailed Description

The Lock lets multiple threads synchronize the running of critial sections of code or the accessing of shared memory. The object acts as what the pthreads documentation calls a "mutex".

Constructor & Destructor Documentation

◆ Lock()

DD::Image::Lock::Lock ( )
inline

The constructor creates the lock unlocked.

◆ ~Lock()

DD::Image::Lock::~Lock ( )
inlinevirtual

Destroys the lock. It does not matter if it is locked or not.

Member Function Documentation

◆ lock()

void DD::Image::Lock::lock ( )
inline

When this returns, the calling thread will "own" the lock.

If no thread owns the lock this will return immediately.

If another thread owns the lock this will block (not return) until that other thread calls unlock().

If this thread already owns the lock the result is undefined!!! To avoid this, use the class RecursiveLock.

Referenced by DD::Image::FileRead::closeFile(), DD::Image::Image_Cache::fileSize(), DD::Image::Thread::getRunningThreadsInfo(), DD::Image::LUT::Linear(), DD::Image::FileReader::lock(), DD::Image::FileReader::read(), DD::Image::Image_Cache::remove(), DD::Image::Image_Cache::remove_oldest_files(), DD::Image::Thread::running(), DD::Image::Thread::spawn(), DD::Image::Thread::terminate_all(), DD::Image::Thread::thisThread(), DD::Image::FileReader::unlock(), and DD::Image::Thread::wait().

◆ spinlock()

void DD::Image::Lock::spinlock ( )
inline

This has the same result as lock(), but it works by spinning. This is faster than doing the system call but it keeps the processor busy looping this thread. You should use this call if and only if:

  • the lock is held by other threads for very short periods of time (such as a dozen or so assignment statements)
  • There is high contention (i.e. there is a good chance that an initial attempt to grab the lock will fail, as this is no faster than the normal lock() on immediate success).

◆ unlock()



©2024 The Foundry Visionmongers, Ltd. All Rights Reserved.
www.foundry.com