DD::Image::Lock Class Reference

Inherited by DD::Image::RecursiveLock, and DD::Image::SignalLock.

List of all members.

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

DD::Image::Lock::Lock ( ) [inline]

The constructor creates the lock unlocked.

DD::Image::Lock::~Lock ( ) [inline, virtual]

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


Member Function Documentation

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.

Reimplemented in DD::Image::RecursiveLock.

Referenced by DD::Image::FileRead::closeFile(), DD::Image::Image_Cache::fileSize(), DD::Image::Thread::getRunningThreadsInfo(), DD::Image::LUT::Linear(), DD::Image::RecursiveLock::lock(), 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().

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).