Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How to make an update immediately available to all CPUs

2 views
Skip to first unread message

Hovik Melikyan

unread,
Mar 27, 2004, 6:08:18 AM3/27/04
to

I'm sorry, this is almost certainly a repeating post.

Q: What is the portable way for setting a plain int variable such that the
new value is immediately available to all CPU's on SMP?

Is it sufficient to surround the assignment with a mutex lock (and do
nothing special when reading the variable)?

Thanks,

--
HM


SenderX

unread,
Mar 27, 2004, 6:11:29 AM3/27/04
to
> Is it sufficient to surround the assignment with a mutex lock (and do
> nothing special when reading the variable)?

You would need to ensure correct memory visibility when reading. You would
want acquire semantics.


Hovik Melikyan

unread,
Mar 27, 2004, 8:46:33 AM3/27/04
to

"SenderX" <x...@xxx.com> wrote in message
news:Bjd9c.16066$K91.53981@attbi_s02...

What is 'acquire semantics' in terms of POSIX calls?

--
HM


Alexander Terekhov

unread,
Mar 27, 2004, 10:08:59 AM3/27/04
to

Hovik Melikyan wrote:
[...]

> What is 'acquire semantics' in terms of POSIX calls?

Mutex acquisition and joining a thread, for example. An operation
with acquire semantics prevents subsequent load and store accesses
{to shared data} from being performed before the acquire operation.
It can be viewed as a memory access operation that is performed in
conjunction with the "hoist-load" and the "hoist-store" reordering
constraints (barriers) applied with respect to the subsequent load
and store accesses {to shared data}. Release semantics (sink-load
and sink-store) are used on the other side.

regards,
alexander.

Hovik Melikyan

unread,
Mar 27, 2004, 10:32:33 AM3/27/04
to

"Alexander Terekhov" <tere...@web.de> wrote in message
news:4065990B...@web.de...

So likewise, 'release semantics' is defined as: prevents all preceding load
and store operations from being performed after the release operation? If
so, and if I understand it right, mutex acquire/release around the
assignment is sufficient for the reader thread to see the result immediately
without applying acquisition.

--
HM


Alexander Terekhov

unread,
Mar 27, 2004, 11:03:57 AM3/27/04
to

Hovik Melikyan wrote:
[...]

> So likewise, 'release semantics' is defined as: prevents all preceding load
> and store operations from being performed after the release operation?

Yep (optimizations aside for a moment).

> If so, and if I understand it right, mutex acquire/release around the
> assignment is sufficient for the reader thread to see the result immediately
> without applying acquisition.

No. The problem is the visibility of the dependent data -- you'll
need both acquire and release (finer grained "hoist" and "sink"
barriers for loads and stores [rwlocks and DCSI/DCCI like stuff]
aside for a moment).

http://www.crhc.uiuc.edu/ece412/papers/models_tutorial.pdf

If you don't have any dependent data, then atomicity and "not-out-
of-thin-air" safety/visibility is sufficient (no need for acquire-
release protocol).

regards,
alexander.

Hovik Melikyan

unread,
Mar 27, 2004, 12:13:19 PM3/27/04
to
"Alexander Terekhov" <tere...@web.de> wrote in message
news:4065A5ED...@web.de...

> > If so, and if I understand it right, mutex acquire/release around the
> > assignment is sufficient for the reader thread to see the result
immediately
> > without applying acquisition.
>
> No. The problem is the visibility of the dependent data -- you'll
> need both acquire and release (finer grained "hoist" and "sink"
> barriers for loads and stores [rwlocks and DCSI/DCCI like stuff]
> aside for a moment).
>
> http://www.crhc.uiuc.edu/ece412/papers/models_tutorial.pdf
>
> If you don't have any dependent data, then atomicity and "not-out-
> of-thin-air" safety/visibility is sufficient (no need for acquire-
> release protocol).
>

Yes, the original question was about a plain int variable.

Thanks for the asnwers, Alexander!

The next question is does the i386 LOCK instruction provide acquire and/or
release semantics? In other words, is it possible to replace mutex locking
of the assignment operation with LOCK MOV on i386 for better performance?

--
HM


Alexander Terekhov

unread,
Mar 27, 2004, 12:36:12 PM3/27/04
to

Hovik Melikyan wrote:
[...]

> The next question is does the i386 LOCK instruction provide acquire and/or
> release semantics?

<quote source=Intel Itanium Architecture Software Developer's Manual>

6.3.4 Memory Ordering Interactions

IA-32 instructions are mapped into the Itanium memory ordering model as
follows:

- All IA-32 stores have release semantics

- All IA-32 loads have acquire semantics

- All IA-32 read-modify-write or lock instructions have release and
acquire semantics (fully fenced).

</quote>

regards,
alexander.

0 new messages