Is this code 'thread safe'? I.e., can it be accessed by more than one thread at the same time?

Short answer: No. As noted above, the code assumes a single thread of execution, using an event loop - rather than multiple threads - for concurrency. This generally makes the code much easier to debug, and much easier to port across multiple operating systems, which may have different thread APIs, or no thread support at all. (For even stronger arguments along these same lines, see John Ousterhout's presentation.)
Therefore, although it's true to say that the code is not 'thread safe', it's also somewhat misleading. It's like saying that a high-speed rail carriage is not 'airworthy'.

Longer answer: More than one thread can still use this code, if only one thread runs the library code proper, and the other thread(s) communicate with the library only by setting global 'flag' variables (such as event loop 'watch variables'), or by calling 'event triggers'. (Note that "triggerEvent()" is the only LIVE555 function that may be called from an external (i.e., non-LIVE555) thread.)

Another possible way to access the code from multiple threads is to have each thread use its own "UsageEnvironment" and "TaskScheduler" objects, and thus its own event loop. The objects created by each thread (i.e., using its own "UsageEnvironment") must not interact (except via global variables). Such a configuration is not recommended, however; instead, it is safer to structure such an application as multiple processes, not multiple threads.

In any case, when using the "LIVE555 Streaming Media" code, you should be familiar with event-driven programming, and understand that an event-driven application can perform at least as well as one that uses threads (unless you're actually running on a multiprocessor, in which case it's usually simpler to have your application consist of multiple processes (not just threads) - one running on each processor). Note, in particular, that you do not need multiple threads in order to transmit (or receive) multiple streams concurrently.

They say to create process rather than to create thread now the problem is when i saw the create process api it takes the path of the exe but i have to execute the code rather than to run the exe,how can it be done.Please guide

1 solution

Solution 1

Yes I have come accross a very similar issue to this. There is a way but it's not very clean.
Instead of using Live555 directly use FFMPEG which includes Live555 internally. You can then use multiple threading if you follow one absolutely strict rule.
Only allow one thread at a time to run the setup or teardown code that creates or destroys the video stream.
Once a stream is up and running you can allow the next thread to create another one but not until.
When you want to shut down only allow one thread at a time to call the functions to end a stream or your app may lock up on exit.
To do this you're going to need your own Mutex or Critical Section and a wrapper of just a few lines through which to call FFMPEG. I can't ship you one or paste it because it doesn't belong to me but I can tell that it can be done and works very reliably once you get it right.
The hardest part may well be to get a proper up to date Windows build of FFMPEG itself.

Thanks for the reply sir but the first of all problem is my app is ready in live 555 i can't use ffmpeg and regarding setup and teardown request one thread is executing that only once the problem u can check here http://stackoverflow.com/questions/14752569/live-media-proxy-server-issue-or-am-i-doing-wrong
more precisely

That looks like a different problem that doesn't involve Live555 directly at all but is to do with sockets and a proxy server. That's going to take some hard work to debug but I'm not sure I can help you much beyond saying that most servers like that use a thread pool and if you're only using 1 thread in Live555 you're going to need to multiplex the stream yourself which will make controlling it more difficult.