[alsa-devel] [PATCH 05/10] ALSA: axd: add buffers manipulation files
Mark Brown
broonie at kernel.org
Wed Aug 26 20:43:23 CEST 2015
On Mon, Aug 24, 2015 at 01:39:14PM +0100, Qais Yousef wrote:
> + /*
> + * must ensure we have one access at a time to the queue and rd_idx
> + * to be preemption and SMP safe
> + * Sempahores will ensure that we will only read after a complete write
> + * has finished, so we will never read and write from the same location.
> + */
In what way will sempahores ensure that we will only read after a
complete write?
> + buf = bufferq->queue[bufferq->rd_idx];
So buffers are always retired in the same order that they are acquired?
> +int axd_bufferq_put(struct axd_bufferq *bufferq, char *buf, int buf_size)
> +{
> + int ret;
> +
> + if (!bufferq->queue)
> + return 0;
> +
> + if (buf_size < 0)
> + buf_size = bufferq->stride;
We've got strides as well? What is that?
> +void axd_bufferq_abort_take(struct axd_bufferq *bufferq)
> +{
> + if (axd_bufferq_is_empty(bufferq)) {
> + bufferq->abort_take = 1;
> + up(&bufferq->rd_sem);
> + }
> +}
> +
> +void axd_bufferq_abort_put(struct axd_bufferq *bufferq)
> +{
> + if (axd_bufferq_is_full(bufferq)) {
> + bufferq->abort_put = 1;
> + up(&bufferq->wr_sem);
> + }
> +}
These look *incredibly* racy. Why are they here and why are they safe?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20150826/6b8e936c/attachment.sig>
More information about the Alsa-devel
mailing list