Paul,
I saw you pointing to the problematic usage of mutex with
ringbuffers a couple of times now. In the most recent case
you mentioned a solution of yours without mutices (sorry,
I can't find the reference anymore ... probably was on LAD).
To me it's not clear why protecting a ringbuffer with a mutex
is evil. Is it simply the problem of "abuse", in the sense of one client
locks the mutex longer than necessary (i.e. longer than just
copying data to/from the buffer), or are there other reasons,
like overhead considerations due to locking/unlocking a mutex
(implementation details of pthread_mutex_...), or whatever?
I'm curious about how you manage to safely access a ringbuffer
in a multithreading environment without using a mutex lock. I
have a background in programming flip-chip die-bonding
machines with a dedicated realtime OS (VxWorks), and the
topics discussed here in the context of audio-processing sound
quite familiar to me. However, I have very little experiance with
linux in this area, so maybe you can give me some clues ...
Thank you,
Wolfgang
----- Original Message -----
From: "Paul Davis" <[EMAIL PROTECTED]>
To: "Tom Browne" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, November 22, 2001 2:43 PM
Subject: Re: [Alsa-devel] Restarting when in async mode
> thread 1:
>
> while (1) {
> wait_for_disk_data_needed();
> fill_buffers ();
> }
>
> thread 2:
>
> while (1) {
> wait_for_audio_to_be_possible ();
> write_to_audio_interface_from_buffers ();
> }
>
> well, that looks better, except if the implementation of
> fill_buffers() and write_to_audio_interface_from_buffers() uses a
> mutex and its not used "appropriately", this design will still work in
> some cases and cause dropouts in others.
>
>
> --p
>
> _______________________________________________
> Alsa-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
