Messages in this thread | | | From | "Joseph Seigh" <> | Subject | Re: What does atomic_read actually do? | Date | Sun, 19 Dec 2004 18:50:54 -0500 |
| |
On Sun, 19 Dec 2004 17:21:06 -0500, Robert Love <rml@novell.com> wrote:
> On Sat, 2004-12-18 at 15:43 -0500, Joseph Seigh wrote: > >> > it does so on *x86 >> >> Is this documented for gcc anywhere? Just because it does so doesn't >> mean it's guaranteed. > > Listen to what Arjan is saying: It is not a compiler feature. x86 > already guarantees that an aligned word-size read is atomic in the > nothing-can-interleave sense. > I'm aware of that. I'm not asking a question about x86 architecture. I'm asking what guarantees that the compiler will load the int using one MOV instruction since there's nothing in the C standard that requires that, even for volatile. I think it's unlikely the compiler would use multiple loads a byte at a time but it really requires a compiler person to authoritatively make that statement.
It's a big problem getting support for threaded programming in C since the C standard doesn't acknowlege threads. For Posix threads, Posix had to come up with a separate compliance certification for C compilers. So when you use posix pthreads, you have to use a posix compliant compiler to ensure your program will work correctly.
It's the same issue here. The atomic functions are another thread api. What's the assurance that gcc supports this api correctly? There was the possibility since the C standard leaves it implementation dependent what constitutes volatile access, that gcc did something special there. But the gcc documentation says this for volatile, "There is no guarantee that these reads and writes are atomic, especially for objects larger than int."
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Volatiles.html#Volatiles
Joe Seigh
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |