|
Loading...
|
gcc-help@gcc.gnu.org
[Prev] Thread [Next] | [Prev] Date [Next]
Re: SUSv3's "memory location" and threads Ian Lance Taylor Thu Aug 30 00:03:20 2007
"Adam Olsen" <[EMAIL PROTECTED]> writes:
> For example, if I had "struct { char foo; char bar[3]; }", where my
> first thread had a pointer to foo and was modifying it, while my
> second thread had a pointer to bar and was modifying it, would that
> meet the requirements? My understanding is that a C compiler can (and
> in many cases, will) use larger writes so long as they appear the same
> for a single-threaded program; this obviously breaks threading though.
Yes, that can happen.
> Is there a specific variable size or alignment at which I can be sure
> (portably, etc) that there will be no larger writes, and that I can
> use locks correctly?
Well, volatile sig_atomic_t (sig_atomic_t is defined in <signal.h>) is
guaranteed to be safe in this scenario. The C and C++ standards do
not provide any other guarantees, as they do not define thread
support.
That aside, if you use locks correctly, I believe you should be safe
in practice if you stick to variables which match the register size of
the processor, or variables which are not in structs.
Ian
- SUSv3's "memory location" and threads Adam Olsen 2007/08/30
- Re: SUSv3's "memory location" and threads Ian Lance Taylor 2007/08/30 <=
- Re: SUSv3's "memory location" and threads Adam Olsen 2007/08/30
- Re: SUSv3's "memory location" and threads Ian Lance Taylor 2007/08/30
- Re: SUSv3's "memory location" and threads Adam Olsen 2007/08/30
- Re: SUSv3's "memory location" and threads Ian Lance Taylor 2007/08/30
- Re: SUSv3's "memory location" and threads Adam Olsen 2007/08/30
- Re: SUSv3's "memory location" and threads Darryl Miles 2007/08/30
- Re: SUSv3's "memory location" and threads Adam Olsen 2007/08/30
Re: SUSv3's "memory location" and threads Darryl Miles 2007/08/30
- Re: SUSv3's "memory location" and threads Ian Lance Taylor 2007/08/30
Re: SUSv3's "memory location" and threads Brian Dessent 2007/08/30