RE: [Ccrtp-devel] SingleRTPSessionPool is not thread safe.

[Jörgen Terner]

Hi!

Thank you for the quick answer!

Well, after my modifications the pool appear to be stable. When I increased the 
number of concurrent sessions, however, the playouts began to sound really bad. 
It looked like the single thread could not serve all the sessions fast enough. 
I experienced that the quality was reduced quite a bit even with as few as 200 
sessions.

I've used sipp (sourceforge) to put some load on the application and then 
called in using Kapanga (http://www.kapanga.net). When a call is connected, the 
application starts to play a prompt. When using a single thread for each RTP 
session, the response time was very good and the quality to. Unfortunately the 
number of threads increased rapidly (of course) and the CPU went close to 100% 
spending a lot of time in kernel switching between the threads. When using a 
single session pool that served all sessions the CPU was not used as heavily 
but the response time was bad and the playout quality was bad to.

I suppose that I could use a set of session pools, but I cannot see how it 
would fit in the application design. Which session should be inserted into 
which pool?

Now, I've started to use a traditional consumer/producer approach:
I have a single threadpool (static in the application) with a configurable 
amount of threads. The pool owns a queue of jobs. All threads waits on a 
condition variable and when a job is inserted, the condition variable is 
triggered. This way I have a common place to but all session jobs.

I have just finished the implementation and have just started to test it. The 
initial test runs, however, is promising.

-Jörgen


On Wed, Mar 15, 2006 at 11:42:17AM +0100, Jörgen Terner wrote:
> 
> Hi all!
> 
> I've tried to use the SingleRTPSessionPool. After several crashes I realized 
> that it is not thread safe. Insertions and deletions are safe but the main 
> loop is not! There is little point in protecting insertions and deletions if 
> the code that reads the list is not protected.
> 
> I've modified the pool-class so that it seems to work but because the number 
> of concurrent sessions are quite large (Minimum requirement ~500) the thread 
> that serves the list of sessions is not given enough time to to its job. I've 
> tried to increase the thread priority but still, the sessions are not served 
> fast enough.
> 

Yes, the session pool stuff is quite "experimental". So it looks like after 
your modifications it becomes quite stable and able to handle a large number of 
sessions?

> My current implementation instead inserts "session-jobs" into a thread pool 
> with a larger amount of threads. The run-method of the session-jobs I've 
> copied from the SingleThreadRTPSession class as in the code below. After each 
> run, the jobs are reinserted into the pool until they are marked as stopped. 
> I'm not currently using commoncpp:s thread-library så I had to comment out 
> the calls to setCancel. Potential problem? 
> 

I would say it depends on how you handle threading, but as long as there are no 
thread cancellations involved, commenting those lines should have no effect.

The idea of "session-jobs" looks very interesting. It could be added as a new 
form of session pool. Could you clarify how would it differ from using a set of 
single-threaded session pools?

> If someone is interested in my modifications to the SingleRTPSessionPool, 
> I've added a support request where my version of the session pool is attached 
> (https://savannah.gnu.org/support/index.php?func=detailitem&item_id=105229).
> 
> Any thoughts?
> 

Great patch! Hope to be able to merge this and other support requests soon for 
a new release!

Basically I would say that any pooling/threading/whatever model that reveals 
useful for a certain application can (and should) be added to the library.