[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