Detailed Description

Threading functions.

The Mutex and Thread classes for WIN32 are almost literal copy and pastes of the functions of wxWindows2.4.2. The implementation has changed a little bit to use more of the LASS utility functions. The most noticible difference is in the thread class where the Delete is not implemented, due to too large dependencies. The Critical Section on WIN32 is an own implementation, just like all the UNIX Posix threading stuff.

A little word on synchronization: in windows there are quite a few synchronisation primitives and synchronized objects. Only the most common are implemented and wrapped in the LASS environment: Mutex : system-wide synchronisation object between processes/threads. Mutexes set in one process can be unlocked in another one. That is the theory. In practice with the LASS wrapping, there is no possibility to reference these mutexes in other processes, named mutexes are not supported. Mutex are rather heavyweight structures. Cannot be used for intrathread synchronisation AFAIK [TDM] CriticalSection : process-wide synchronisation object between threads. Lightweight construction. Cannot be used for intra-thread synchronisation. Condition: this corresponds with MS Windows Events, can be used for interprocess/ interthread and intrathread synchronisation. Not implemented in UNIX build.

Data Structures
class	lass::util::RWLock
	Lean and mean synchronisation object, without OS support. More...

class	lass::util::Mutex
	Mutex. More...

class	lass::util::CriticalSection
	CriticalSection. More...

class	lass::util::Condition
	Condition. More...

class	lass::util::Thread
	A base class for threads. More...

class	lass::util::ThreadLocalStorage
	A primitive to provide Thread Local Storage functionality. More...

class	lass::util::ThreadLocalVariable< T >
	A primitive to provide Thread Local Storage functionality for a first-citizen class. More...

class	lass::util::Semaphore
	Lean and mean synchronisation object, without OS support. More...

class	lass::util::LockerBase
	Common base class for lockers. More...

class	lass::util::DefaultConsumer< TaskType >
	Default consumer calls operator() of task. More...

class	lass::util::Spinning
	implementation of ThreadPool's IdlePolicy More...

class	lass::util::Signaled
	implementation of ThreadPool's IdlePolicy More...

class	lass::util::SelfParticipating< TaskType, ConsumerType, IdlePolicy >
	implementation of ThreadPool's ParticipationPolicy More...

class	lass::util::NotParticipating< TaskType, ConsumerType, IdlePolicy >
	implementation of ThreadPool's ParticipationPolicy More...

class	ThreadPool
	Production-Consumer concurrency pattern. More...

Macros
#define	LASS_LOCK(iLock)
	Locks a iLock and starts a scope block in which it remains locked.

Typedefs
typedef Locker< Mutex >	lass::util::MutexLocker
	typedef of Locker for Mutex

typedef Locker< CriticalSection >	lass::util::CriticalSectionLocker
	typedef of Locker for CriticalSection

typedef Locker< Semaphore >	lass::util::SemaphoreLocker
	typedef of Locker for Semaphore

Enumerations
enum	lass::util::LockResult { lass::util::lockSuccess , lass::util::lockBusy }
	Return code for lock functions. More...

enum	lass::util::WaitResult { lass::util::waitSuccess , lass::util::waitTimeout }
	Return code for wait functions. More...

enum	lass::util::ThreadKind { lass::util::threadDetached , lass::util::threadJoinable }
	ThreadKind. More...

Functions
size_t	lass::util::numberOfProcessors ()
	Return highest id of processor + 1, in this machine.

size_t	lass::util::numberOfAvailableProcessors ()
	Return total number of processors in machine that are online.

bool	lass::util::isAvailableProcessor (size_t processor)
	Check whether a processor is avaialable.

Macro Definition Documentation

◆ LASS_LOCK

#define LASS_LOCK ( iLock )

Value:

if (const ::lass::util::LockerBase& LASS_UNUSED(lassUtilImplLocker) = ::lass::util::makeLocker(iLock))

Locks a iLock and starts a scope block in which it remains locked.

Author: [Bramz]

This macro starts a scope block through a if/else construct where the lock will be locked on entering the scope, and will be unlocked on leaving the scope. You can use this scope in two ways: by using the braces:

LASS_LOCK(lock)
{
    // locked
    doSomethingWhileLocked();
}
// unlocked

Because the macro uses an if/else construct, you can ommit the braces if you only need one statement in the locked scope:

LASS_LOCK(lock) doSomethingWhileLocked();

requirements for iLock:: iLock can be of any type that implements two methods lock() and unlock(), that have to do the obvious thing. Two excellent types to be used are lass::util::Mutex and lass::util::CriticalSection.

references:: Concurrent Acces Control & C++, C/C++ Users Journal, January 2004

Note: Guess what, for some reason bill gates might know, LASS_UNIQUENAME(lassUtilImplGenericLocker) causes troubles in the win32_vc7_d build. huray! Does the concatenation fails? It seems not, since in the preprocessor files everything seems fine. And yet, it breaks. Hence, we had to give up on it, there's only lassUtilImplGenericLocker now. I don't think that will cause any problems, since it's inside an if/else scope block. But if you get name conflicts on LASS_LOCK, this might be the reason ...

Definition at line 619 of file thread.h.

Referenced by lass::io::BinaryOSocket::setSocket().