Subj : Re: 'volatile' Rules To : comp.programming.threads From : David Schwartz Date : Tue Jun 07 2005 03:14 pm "Joe Seigh" wrote in message news:w92dneQAaIfdlDvfRVn-gA@comcast.com... > There are a finite amount of registers. You can't put an indefinite > amount of variables in registers at the same time no matter what the > standard says. And all setjmp/longjmp do is basically save/restore > registers. Furthermore, C has no mechanism to force stuff to be > register only. Basically, everything starts out as register class > and the compiler looks for reasons to move to memory class, e.g. > external references. It's not clear how much C actually knows about > signal handling so you might have to be careful how you set up stuff > that's shared between a signal handler and the main program. You > have to ensure the compiler recognizes that the data may be shared. You're way out in left field with this one. There is no reason you would want to force stuff to be register only, 'setjmp'/'longjmp's purpose is to act as a 'goto', not to save and restore information other than program position. These functions manipulate the stack context and program counter, not general-purpose registers. >> In practice most programs using signals assume slightly more than >> that, even though it's not formally guaranteed by ISO C or POSIX. >> They assume that volatile variables which fit into machine word >> are accessed atomically wrt. a signal handler. I haven't heard of >> a platform where this is not true. > > They assume too much. Volatile doesn't mean anything here. There is a sig_atomic_t for this where atomicity is guaranteed w.r.t. a single processor and signals. >> This is the cruical point. They don't need memory barriers, so the >> only things they need are: >> - atomic access (true in practice for small types) >> - that the compiler won't reorder accesses wrt. other side effects >> and wrt. one another (this is given by volatile) > It's not guaranteed by volatile. Correct. DS .