Hi Fons, Thanks for your ideas. This is how I've started to do it but was worried I was going down the wrong path. Thanks for the flag tips, I'll do that. Cheers, Andrés Fons Adriaensen wrote:

Thanks all for the thoughful discussion. Cheers, Andrés Fons Adriaensen wrote:

On Sat, 2007-07-07 at 02:34 +0200, Fons Adriaensen wrote: Is there any advantage in using a simple flag instead of a semaphore and sem_trywait()? --ll

Am Samstag, 7. Juli 2007 schrieb Lars Luthman: A semaphore might mislead you to use wait()/lock() in the wrong thread... And if you only sync two threads and each of them has its own flag (for write), there shouldn't be any race-conditions and its easier to use a bool-variable than semaphore->bla(). Arnold -- visit http://www.arnoldarts.de/ --- Hi, I am a .signature virus. Please copy me into your ~/.signature and send me to all your contacts. After a month or so log in as root and do a rm / -rf. Or ask your administrator to do so...

On 7/7/07, Lars Luthman <lars.luthman(a)gmail.com> wrote: Mostly yes, assuming the storage location is word-aligned which it normally will be (due to the compiler). I vaguely recall that some now old Sun SPARC and Motorola 68K machines may have presented problems in that area. But, as a practical constraint it should work OK (AFAIK). It is generally necessary for an SMP implementation to guarantee coherency on a cache line granularity. Since a word-aligned word will generally not cross cache lines, you can assume that hardware will ensure you at least always get either the old or the new value when looking at it. The problem with a largish struct is that hardware often does not ensure that another thread sees only the old or new value. It could see the new value of the flag but the old value of some of the other fields. If so, you need a memory fence instruction of some sort. -- joq

On 7/6/07, Fons Adriaensen <fons(a)kokkinizita.net> wrote: Beware! Flags are not enough to guarantee that you get a coherent copy of the structure. The safest technique is using "guard" words at the start and end of the structure. The process thread updates the guard word at the beginning to a unique value (time of day, or increment an integer). Then, it performs the update. Last it copies the first guard word to the one at the end. The code in the other thread must copy the entire struct to another memory area, then check that the guard words are equal. If not, it loops back and tries the copy again. After several tries, it should usleep() a while before trying some more. Something like this (see libjack/transclient.c)... /* copy a JACK transport position structure (thread-safe) */ void jack_transport_copy_position (jack_position_t *from, jack_position_t *to) { int tries = 0; long timeout = 1000; do { /* throttle the busy wait if we don't get the answer * very quickly. See comment above about this * design. */ if (tries > 10) { usleep (20); tries = 0; /* debug code to avoid system hangs... */ if (--timeout == 0) { jack_error ("hung in loop copying position B"); abort(); } } *to = *from; tries++; } while (to->unique_1 != to->unique_2); } This is adequate for normal SMP Intel and AMD machines with strong memory ordering. On some other platforms, a memory fence instruction is probably needed after updating the struct.. The spin wait is mainly for SMP. On a UP it does not help, so you need to sleep. The reason for doing something comp;icated like this rather than using a mutex is that there are realtime priority inversion problems if the proces thread has to wait on a mutex, because the other thread is not running with SCHED_FIFO priority. -- joq

On 7/7/07, Fons Adriaensen <fons(a)kokkinizita.net> wrote: And on what platform. Beware of SMP hardware with non- coherent caches. In general, it is not portable to assume that stores done by one thread are seen in the same order in another thread. On most PC-class Intel or AMD systems that does work. That is called "strong storage ordering". PowerPC, however, only guarantees "weak storage ordering". Some NUMA machines my not guarantee any at all. This is a tradeoff between hardware performance and programming convenience. Some system designs opt for the former. The OP specified that "only the jack callback writes to the structures". My suggestion would not work in the general case of multiple update threads. For that, you need some kind of atomic compare-and-swap or increment operation or a very high resolution timer. -- joq