Re: [LAD] Noob Q: Pthreads the way to go?

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: <fons@...>
To: <linux-audio-dev@...>
Date: Friday, November 13, 2009 - 1:00 pm

On Fri, Nov 13, 2009 at 02:15:27AM +0000, Harry Van Haaren wrote:

> That's the background to this question: Is mutex locking the only way to

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

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAD] Noob Q: Pthreads the way to go?, Harry Van Haaren, (Fri Nov 13, 2:15 am)
Re: [LAD] Noob Q: Pthreads the way to go?, Harry Van Haaren, (Sun Nov 15, 12:01 am)
Re: [LAD] Noob Q: Pthreads the way to go?, , (Fri Nov 13, 1:00 pm)
Re: [LAD] Noob Q: Pthreads the way to go?, Jussi Laako, (Fri Nov 13, 11:48 am)
Re: [LAD] Noob Q: Pthreads the way to go?, Markus Schwarzenberg, (Fri Nov 13, 7:57 am)
Re: [LAD] Noob Q: Pthreads the way to go?, Raymond Martin, (Fri Nov 13, 10:13 am)