Conferencing API Programming Guide — August 2006 23
Application Development Guidelines
5.7 Multiprocessing Considerations
Having multiple processes acting on the same board is undesirable. It is recommended to use a
single process per board, or a single process for all boards, rather than more than one process acting
on the same board. Consider the scenario where there are multiple boards in the system and each
board is being controlled by a different process.
The following considerations apply when multiple processes control the same board:
•You must provide your own synchronization to manage resources in each process.
•If process A creates a conference and process B wants to use that conference, process A must
pass the name of the conference to process B.
•If process A deletes a conference and process B has a handle to that conference, then process B
can no longer use that conference. Process A must notify process B of its action.
5.8 Multithreading Considerations
The following considerations apply to multithreading:
•The conferencing library supports multithreading. You can manage multiple conferences or
multiple boards within the same thread; however, it is not recommended that you manage the
same conference or the same board across multiple threads.
•The resource counts returned by cnf_GetDeviceCount() are a snapshot in time. If another
thread is adding/deleting a party or creating/deleting a conference, the counts will change and
the thread will no longer have the most current count. There is a gap between the time you
issue this function and when you actually use the resources. Be sure that threads use
synchronization when making decisions based on the counts returned by
cnf_GetDeviceCount().
•While the API functions allow for concurrent use of party, conference and board handles, you
must be aware of “logical” concurrency issues, such as maintaining the count of resources.
The cnf_GetDeviceCount( ) function returns a snapshot of available parties and maximum
parties that can be added to a conference. Because it is a snapshot of the state of the firmware
at any given time, the values returned are only valid until other parties and conferences are
added or removed.
In a multithreaded application, you should maintain local counts that are obtained when the
application initializes (through cnf_GetDeviceCount( )) and protect those counts with
mutexes as needed; for example, if two or more threads in the application need to make
decisions based on the number of parties and conferences available at any given time. By
doing so, race conditions can be avoided; for example, if a thread thinks one more party
resource is available while another thread consumes it.