[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Ccrtp-devel] SingleRTPSessionPool is not thread safe.
From: |
Jörgen Terner |
Subject: |
RE: [Ccrtp-devel] SingleRTPSessionPool is not thread safe. |
Date: |
Thu, 16 Mar 2006 08:10:18 +0100 |
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.