Subject: [linux-audio-dev] shared memory synchronization
From: est_AT_hyperreal.org
Date: to syys 30 1999 - 16:14:33 EDT
Some of the recent discussions, especially the anomalous behavior
observed by Juhana, have got me thinking about three issues involving
the use of shared memory between threads and among processors.
1) Correct volatile declarations are important. It would be nice if C
guaranteed that these aren't needed if you have function calls between
uses of a pointer, but that doesn't seem to be the case. BTW, on the
other end of the aliasing spectrum, c9x has a `restrict' type
qualifier that allows the programmer to provide guarantees against
aliasing.
2) Multiprocessor cache synchronization. POSIX guarantees that
certain operations (e.g., pthread_mutex_lock()) will cause this to
occur. Do they under linux? Does the lock/cmpxchgl operation used
by linuxthreads, for example, cause this to happen? This is very
important to me as I'm working on SMP-friendly approaches to garbage
collection and problems here will cause more than imperceptible audio
glitches.
3) What can you atomically read/write without synchronization? The
appended autoconf macro provides a non-guaranteed-but-probably-OK way
of double-checking assumptions in this area.
Eric
dnl AC_CHECK_ATOMICITY(TYPE)
AC_DEFUN(AC_CHECK_ATOMICITY,
[changequote(<<, >>)dnl
dnl The name to #define.
define(<<AC_TYPE_NAME>>, translit(atomic_$1, [a-z *], [A-Z_P]))dnl
dnl The cache variable name.
define(<<AC_CV_NAME>>, translit(ac_cv_atomic_$1, [ *], [_p]))dnl
changequote([, ])dnl
AC_MSG_CHECKING(atomicity of $1)
AC_CACHE_VAL(AC_CV_NAME,
[AC_TRY_RUN([#include <stdio.h>
#include <signal.h>
main()
{
FILE *f=fopen("conftestval", "w");
if (!f) exit(1);
fprintf(f, "%s\n", (sizeof($1) > sizeof(sig_atomic_t)) ? "no" : "yes");
exit(0);
}], AC_CV_NAME=`cat conftestval`, AC_CV_NAME=0, ifelse([$2], , , AC_CV_NAME=$2)\)])dnl
AC_MSG_RESULT($AC_CV_NAME)
AC_DEFINE_UNQUOTED(AC_TYPE_NAME, $AC_CV_NAME)
undefine([AC_TYPE_NAME])dnl
undefine([AC_CV_NAME])dnl
])
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST