Re: [LAD] Noob Q: Pthreads the way to go?
On November 13, 2009 02:56:44 am Markus Schwarzenberg wrote: On Fri, 13 Nov 2009 02:15:27 + Harry Van Haaren harryhaa...@gmail.com wrote: I've googled for c++ cross-platform threading which returned this posthttp://www.codeproject.com/KB/threads/thread_class.aspx. this probably better should have returned: http://www.boost.org/doc/html/thread.html besides this, there is http://sourceware.org/pthreads-win32/ - also works nicely. However, it's C. Do you really need cross-platform threading for Linux audio? If you do need it, for some reason, you might consider using the Qt concurrency framework (with or without Qt GUI stuff). Regards, Raymond ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Noob Q: Pthreads the way to go?
Harry Van Haaren wrote: That's the background to this question: Is mutex locking the only way to ensure that variables are only being accessed by one thread at a time? Is it the right way to go about it? No, there are also semaphores and read-write locks. RW-locks are especially useful in cases where there's a single writer but multiple readers (typically any data distribution). In general, threading is a wrong way to go if you find sharing and locking a lot of data between the threads. Threads should be able to execute fairly independently to properly utilize resources. Naturally there are typically scatter-gather points which are supposed to be short compared to overall thread execution time. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Noob Q: Pthreads the way to go?
On Fri, Nov 13, 2009 at 02:15:27AM +, Harry Van Haaren wrote: That's the background to this question: Is mutex locking the only way to ensure that variables are only being accessed by one thread at a time? Is it the right way to go about it? I've seen quite some strong opinions around the internet on how RT threading should be done, however I still am not fully sure if PosixThreads is the way to go, (due to windows not supporting it). It helps to clearly separate two things: 1. How a multithreaded program can be structured 2. A particular implementation of threads, e.g. Posix. (2) maybe suggests (1), but in fact the two are quite independent. For (1) there are several approaches: A1. Data is shared between threads, access to it is contolled by mutexes. A2. The CSP way: all data used by a thread strictly private to that thread. If another thread needs it, it is copied via a data channel. Threads can sync on data channels, i.e. they can wait for data to arrive. A3. As (A2) but data maybe transferred by just sending a pointer to it. The pointer message transfers ownner- ship - even if a thread could still access the data after having transmitted it, it will not do so until it receives the pointer again. The net result is the same as (A2), but it can be more efficient if large amounts of data have to be moved. A related issue is how to control the threads themselves in an application where threads could be added and removed dynamically: B1. Threads can be 'killed' by other threads. B2. Threads can not be terminated externally, but they are designed to terminate themselves when necessary or on request. (A1, B1) often go together, as do (A2, A3, B2). This is logical, as if thread data is private, only the thread itself can clean up before quitting, so no thread should ever be 'zapped'. The choice between these models is independent of the thread implementation you use. Mixing them in large applications is usually a recipe for trouble. (A1) is somewhat closer to actual low-level threads implementations, while (A2, A3) may require some thin layer on top of them, but such a layer can be made for whatever thread implementation. It also adds a degree of abstraction, and hence portability. Another feature of the CSP inspired models is that they can work on multiprocessor system where each processor has only private memory, and data channels between them are supported by hardware. Coming from a CSP bacground, I certainly do prefer (A2, A3) except maybe for very simple systems, but that could be a very personal preference. Ciao, -- FA Io lo dico sempre: l'Italia รจ troppo stretta e lunga. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] Prize for a free-for-all audio plug-in / audio
Thought you might like to know. Nice chance to win some money for many devs in here. Please, spread this. http://www.kvraudio.com/developer_challenge_2009.php Description on the web: --- The KVR Developer Challenge 2009 is for anyone who develops audio plug-ins or applications (i.e. a developer). The challenge is to create and release a brand new free audio plug-in or audio application that will benefit the community at large. Creativity is key, it can be as simple or as complex as you want - KVR members will vote on the entries and pick the eventual winner. Anyone can make a donation via PayPal, the prize fund will be distributed to the eventual winners (details below). -- Carlos sanchiavedraz * Musix GNU+Linux http://www.musix.es ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Prize for a free-for-all audio plug-in / audio
On Fri, 13 Nov 2009, Carlos Sanchiavedraz wrote: Thought you might like to know. Nice chance to win some money for many devs in here. Please, spread this. http://www.kvraudio.com/developer_challenge_2009.php It looks like they're voting now, and that the window for entries closed Oct 28, 2009. -gabriel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
