Thread Safe

---

Detailed Description

TODO.

[ Email questions or comments ] [ Join the mailing list ]

Classes
class	phCondition
	This class implements a platform independent condition variable mechanism. Not every platform has it's own implementation and other algorithms were found to create condition variables where they aren't natively supported. These algorithms use a combination of mutexes and semaphores to emulate the behavior of condition variables. While it might seem straight forward to use the algorithms, it required a bit of work. The implemented algorithm using Win32 API and using the Phission API for the Blackfin was derived from: http://www.cs.wustl.edu/~schmidt/win32-cv-1.html. More...
class	phConditionCounter
	This is a Condition Counter class that allows for threads to block while waiting for a specific value setting. Threads will call phConditionCounter::waitForValue with a value parameter and a conditional operation choice to compare the passed value with the counter value. In order to provide the condition variable functionality, this class inherits from the phCondition class. The phConditionCounter::waitForValue method is a convenience because it simplifies the code at higher levels when a specific value is desired where hard looping or sleeping will impact performance. The waiting doesn't return until the condition is met whereas phConditon will return whenever the condition is signaled. More...
class	phDataObject
	todo. More...
class	phDisplayInterface
	todo. More...
class	phFilter
	todo. More...
class	phImage
	todo. More...
class	phImageCapture
	todo. More...
class	phImageWindow
	todo. More...
class	phListNode
	phListNode is used with the phList class and represents a simple node type that can be added or removed from the list. It doesn't hold any information and classes should be derived from it if a node type that holds information wishes to be implemented. The phObjectNode is one class that inherits from this class and implements new methods specific to the phObjectNode and phObjectList classes. The node inherits from phMutex so that it can be locked when list operations are being performed to make the implementation thread-safe. Whenever the node pointers are being adjusted using phListNode::setNext or phListNode::setPrevious the specific instance of phListNode will be locked so that no other thread can try adjusting the pointers at the same time. The object is also locked in phListNode::getNext and phListNode::getPrevious so no thread can change the pointers while another thread is trying to get access to them. More...
class	phList
	The phList is a thread-safe linked list implementation. The list is locked whenever an operation is being performed on the list. List nodes are only locked if they are being looked at or having the next/previous pointers adjusted. Otherwise, it is possible for multiple threads to access multiple nodes at a time when the list doesn't have a node locked. More...
class	phLiveObject
	The phLiveObject and phLiveCookie classes are the backbone of the data flow type system. They are used to encapsulate all update and signaling functionality. Any object that wants to use the connect, update and disconnect phLiveObject API should derive from this class. In this manner, any object that also derives from phLiveObject can connect to any other phLiveObject class. These classes must also overload the 'copy' and 'swap' methods of the phObject class. More...
class	phMutex
	phMutex provides platform independent locking mechanisms to the Phission code. The phMutex is a recursive implemented mutex. Multiple mutexes can be obtained by a thread by calling the phMutex::lock() method and each successful phMutex::lock() should be matched with a call to the phMutex::unlock() method. If there isn't one phMutex::unlock() call for every phMutex::lock()/phMutextryLock() call that succeeded, deadlock could occur in other threads that are trying to obtain the lock. Recursive mutexes are necessary for a system such as Phission where a call to the current object's method may also call other methods that belong to the same instance of the object. Those other methods could be called on their own as well. Without recursive mutexes, the one scope calling into another scope (scope being separate methods or blocks of code) will deadlock on the second attempt at locking. More...
class	phObjectNode
	The phObjectNode wraps most of the phListNode methods to provide a phObjectNode interface that doesn't require a user to always wrap the phListNode returned pointers to a phObjectNode pointer. The phObjectNode adds methods to set the phObject pointer that is packaged within the node. The autoDelete_on parameter is used to delete the phObjects in the phObjectNodes when delete is called on the phObjectNode. This allows one to add nodes to the list and forget about deleting the objects if it serves the code. Auto-deleting is disabled by default because the common case dictates that a user will add a phObject and then delete that object manually instead of letting the node do it. More...
class	phObjectList
	The phObjectList is a list that operates with phObjectNodes to create a thread-safe list structure for the storage of any class derived from phObject. This class basically wraps around the phList interface but makes adaptations to take phObject pointers as parameters. In addition, a phObjectList::findObject method will determine if a phObject exists in the list for any purpose such as making sure the phObject exists only once in the list. The methods are renamed to include the term Object so that they will not be mistaken for the phList wrapped methods. The phObjectList also handles much of the creation of the phObjectNode containers by taking only a phObject pointer as a parameter. This greatly simplifies higher level code such as the code in phSystem that makes use of this class. If one wishes the nodes in a phObjectNode to always have the auto delete option enabled, the phObjectNode returned from any of the following methods can be used to enabled it: phObjectList::insertObject phObjectList::enqueueObject phObjectList::pushObject phObjectList::unshiftObject. More...
class	phPipeline
	The pipeline class is the main processing thread within the Phission system. phFilter classes are added to a phPipeline and are processed in the order in which there were added. More...
class	phRWLock
	This class provides a platform independent Reader-Writer class. More...
class	phSemaphore
	This class implements a thread safe portable semaphore class. It extend the normal interface of a semaphore with the phSemaphore::postWaiting and phSemaphore::postMax methods. This semaphore object will keep track of the number of waiting threads at any instance in time to allow them to all be 'woken up' if necessary to permit the proper shutdown or cleanup of a thread or series of threads. Being able to post the maximum number of semaphores possible without any of the threads returning until all the semaphores are posted can be useful in synchronization. Otherwise, the semaphores can be posted one at a time. More...
class	phServerSocket
	todo. More...
class	phSocket
	A simple client-side socket communication layer. More...
class	phSystem
	TODO. More...
class	phThread
	C++ wrapper class for threading. More...
class	phTimeList
	todo. More...

Copyright (C) 2002 - 2007

Philip D.S. Thoren ( pthoren@users.sourceforge.net ) University Of Massachusetts at Lowell Robotics Lab

---