[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.programming.threads

Re: C objects [was Re: Is Itanium the first 64-bit casualty?]

Joe Seigh

7/30/2004 1:31:00 PM



Nick Maclaren wrote:
>
> In article <410A44FF.8E914EE7@xemaps.com>,
> Joe Seigh <jseigh_01@xemaps.com> writes:
> |>
> |> POSIX has a Posix Compliance specification that applies separately from
> |> the C standard. Among other things, it allows statements to be moved
> |> into a locks critical sections, but not out. ...
>
> Well, you might be right. However, since I am a suspicious person,
> and have some reason to believe that you are imagining things, can
> you provide a precise reference? Preferably an IEEE publication
> number, but anything checkable will do.
>

Well, I don't have a copy of the Posix standard but somebody in c.p.t.
can give you the reference. Cross posting to c.p.t.

Joe Seigh
9 Answers

Alexander Terekhov

7/30/2004 2:14:00 PM

0


Joe Seigh wrote:
>
> Nick Maclaren wrote:
> >
> > In article <410A44FF.8E914EE7@xemaps.com>,
> > Joe Seigh <jseigh_01@xemaps.com> writes:
> > |>
> > |> POSIX has a Posix Compliance specification that applies separately from
> > |> the C standard. Among other things, it allows statements to be moved
> > |> into a locks critical sections, but not out. ...
> >
> > Well, you might be right. However, since I am a suspicious person,
> > and have some reason to believe that you are imagining things, can
> > you provide a precise reference? Preferably an IEEE publication
> > number, but anything checkable will do.
>
> Well, I don't have a copy of the Posix standard but somebody in c.p.t.
> can give you the reference. Cross posting to c.p.t.

It (SUS) says "Applications shall ensure that access to any memory
location by more than one thread of control (threads or processes)
is restricted such that no thread of control can read or modify a
memory location while another thread of control may be modifying
it. Such access is restricted using functions that synchronize
thread execution and also synchronize memory with respect to other
threads. The following functions synchronize memory with respect
to other threads: <snip>. Unless explicitly stated otherwise, if
one of the above functions returns an error, it is unspecified
whether the invocation causes memory to be synchronized.
Applications may allow more than one thread of control to read a
memory location simultaneously."

That's it. It allows a lot. ;-)

For starters, given that the term "memory location" is defined
neither by POSIX nor C standard, all threaded POSIX programs
involve "implementation-specific" behavior that might or might
not break them.

regards,
alexander.

--
http://terekhov.de/GPL'ed-S...

Joe Seigh

7/30/2004 2:30:00 PM

0



Alexander Terekhov wrote:
>
> Joe Seigh wrote:
> >
> > Nick Maclaren wrote:
> > >
> > > In article <410A44FF.8E914EE7@xemaps.com>,
> > > Joe Seigh <jseigh_01@xemaps.com> writes:
> > > |>
> > > |> POSIX has a Posix Compliance specification that applies separately from
> > > |> the C standard. Among other things, it allows statements to be moved
> > > |> into a locks critical sections, but not out. ...
> > >
> > > Well, you might be right. However, since I am a suspicious person,
> > > and have some reason to believe that you are imagining things, can
> > > you provide a precise reference? Preferably an IEEE publication
> > > number, but anything checkable will do.
> >
> > Well, I don't have a copy of the Posix standard but somebody in c.p.t.
> > can give you the reference. Cross posting to c.p.t.
>
> It (SUS) says "Applications shall ensure that access to any memory
> location by more than one thread of control (threads or processes)
> is restricted such that no thread of control can read or modify a
> memory location while another thread of control may be modifying
> it. Such access is restricted using functions that synchronize
> thread execution and also synchronize memory with respect to other
> threads. The following functions synchronize memory with respect
> to other threads: <snip>. Unless explicitly stated otherwise, if
> one of the above functions returns an error, it is unspecified
> whether the invocation causes memory to be synchronized.
> Applications may allow more than one thread of control to read a
> memory location simultaneously."
>
> That's it. It allows a lot. ;-)
>
> For starters, given that the term "memory location" is defined
> neither by POSIX nor C standard, all threaded POSIX programs
> involve "implementation-specific" behavior that might or might
> not break them.
>

I think we're looking for the stuff that says there is such as
thing as POSIX compliance for C compilers separate from the
C standard.

Also, is there an explicit reference to that moving of statements
into locked critical regions that you bring up every so often?
You made it sound like there was one. There's a big difference
in saying "Posix allows" vs. saying "Posix does not disallow",
especially when the former implies special knowledge about the
lock functions on the part of the compiler.

Joe Seigh

Alexander Terekhov

7/30/2004 2:42:00 PM

0


Joe Seigh wrote:
[...]
> I think we're looking for the stuff that says there is such as
> thing as POSIX compliance for C compilers separate from the
> C standard.

http://www.opengroup.org/certification/idx...

>
> Also, is there an explicit reference to that moving of statements
> into locked critical regions that you bring up every so often?

No.

> You made it sound like there was one.

"As if" rule.

> There's a big difference
> in saying "Posix allows" vs. saying "Posix does not disallow",
> especially when the former implies special knowledge about the
> lock functions on the part of the compiler.

The Rationale says:

<quote>

Conforming applications may only use the functions listed to
synchronize threads of control with respect to memory access.
There are many other candidates for functions that might also
be used. Examples are: signal sending and reception, or pipe
writing and reading. In general, any function that allows one
thread of control to wait for an action caused by another
thread of control is a candidate. IEEE Std 1003.1-2001 does
not require these additional functions to synchronize memory
access since this would imply the following:

All these functions would have to be recognized by advanced
compilation systems so that memory operations and calls to
these functions are not reordered by optimization.

All these functions would potentially have to have memory
synchronization instructions added, depending on the
particular machine.

The additional functions complicate the model of how memory
is synchronized and make automatic data race detection
techniques impractical.

Formal definitions of the memory model were rejected as
unreadable by the vast majority of programmers. In addition,
most of the formal work in the literature has concentrated
on the memory as provided by the hardware as opposed to the
application programmer through the compiler and runtime
system. It was believed that a simple statement intuitive to
most programmers would be most effective. IEEE Std 1003.1-
2001 defines functions that can be used to synchronize
access to memory, but it leaves open exactly how one relates
those functions to the semantics of each function as specified
elsewhere in IEEE Std 1003.1-2001. IEEE Std 1003.1-2001 also
does not make a formal specification of the partial ordering
in time that the functions can impose, as that is implied in
the description of the semantics of each function. It simply
states that the programmer has to ensure that modifications
do not occur "simultaneously" with other access to a memory
location.

</quote>

Well, POSIX threaded memory model is nothing but sort of
"subset" of the proposed new Java memory model.

http://www.cs.umd.edu/~pugh/java/memoryModel/...
(Final Draft July 27, 2004, 10:38am)

regards,
alexander.

--
http://terekhov.de/GPL'ed-S...

Joe Seigh

7/30/2004 3:08:00 PM

0



Alexander Terekhov wrote:
>
> Joe Seigh wrote:
> [...]
> > I think we're looking for the stuff that says there is such as
> > thing as POSIX compliance for C compilers separate from the
> > C standard.
>
> http://www.opengroup.org/certification/idx...
>
> >
> > Also, is there an explicit reference to that moving of statements
> > into locked critical regions that you bring up every so often?
>
> No.
>
> > You made it sound like there was one.
>
> "As if" rule.

As if nothing. I really need to start taking things you say with
a lot more salt.

>
> > There's a big difference
> > in saying "Posix allows" vs. saying "Posix does not disallow",
> > especially when the former implies special knowledge about the
> > lock functions on the part of the compiler.
>
> The Rationale says:
>
> <quote>
>
> Conforming applications may only use the functions listed to
> synchronize threads of control with respect to memory access.
> There are many other candidates for functions that might also
> be used. Examples are: signal sending and reception, or pipe
> writing and reading. In general, any function that allows one
> thread of control to wait for an action caused by another
> thread of control is a candidate. IEEE Std 1003.1-2001 does
> not require these additional functions to synchronize memory
> access since this would imply the following:
>
> All these functions would have to be recognized by advanced
> compilation systems so that memory operations and calls to
> these functions are not reordered by optimization.
>
> All these functions would potentially have to have memory
> synchronization instructions added, depending on the
> particular machine.
>
> The additional functions complicate the model of how memory
> is synchronized and make automatic data race detection
> techniques impractical.
>
> Formal definitions of the memory model were rejected as
> unreadable by the vast majority of programmers. In addition,
> most of the formal work in the literature has concentrated
> on the memory as provided by the hardware as opposed to the
> application programmer through the compiler and runtime
> system. It was believed that a simple statement intuitive to
> most programmers would be most effective. IEEE Std 1003.1-
> 2001 defines functions that can be used to synchronize
> access to memory, but it leaves open exactly how one relates
> those functions to the semantics of each function as specified
> elsewhere in IEEE Std 1003.1-2001. IEEE Std 1003.1-2001 also
> does not make a formal specification of the partial ordering
> in time that the functions can impose, as that is implied in
> the description of the semantics of each function. It simply
> states that the programmer has to ensure that modifications
> do not occur "simultaneously" with other access to a memory
> location.
>
> </quote>
>
> Well, POSIX threaded memory model is nothing but sort of
> "subset" of the proposed new Java memory model.
>
> http://www.cs.umd.edu/~pugh/java/memoryModel/...
> (Final Draft July 27, 2004, 10:38am)
>

That's just opinion or wishful thinking. While java may allow
movement into a locked critical region, it's undefined for
Posix threads. There's no connection between the Java
memory model and Posix's lack of one.

Joe Seigh

nmm1

7/30/2004 3:18:00 PM

0

In article <410A5D7B.ADEA548A@xemaps.com>,
Joe Seigh <jseigh_01@xemaps.com> wrote:
>Alexander Terekhov wrote:
>>
>> For starters, given that the term "memory location" is defined
>> neither by POSIX nor C standard, all threaded POSIX programs
>> involve "implementation-specific" behavior that might or might
>> not break them.
>>
>I think we're looking for the stuff that says there is such as
>thing as POSIX compliance for C compilers separate from the
>C standard.

We are, indeed. The question is whether that stuff has any more
existence than the Necronomicon.


Regards,
Nick Maclaren.

Alexander Terekhov

7/30/2004 3:45:00 PM

0


Joe Seigh wrote:
[...]
> > "As if" rule.
>
> As if nothing. I really need to start taking things you say with
> a lot more salt.

and pepper. Seriously, I stand by what I said on reordering.

[...]
> That's just opinion or wishful thinking. While java may allow
> movement into a locked critical region, it's undefined for
> Posix threads.

Undefined includes "may allow". What's your problem?

regards,
alexander.

P.S. BTW, POSIX certification stuff can be found here:

http://www.opengroup.org/certification/idx/...

--
http://terekhov.de/GPL'ed-S...

Joe Seigh

7/30/2004 4:05:00 PM

0



Alexander Terekhov wrote:
>
> Joe Seigh wrote:
> [...]
> > > "As if" rule.
> >
> > As if nothing. I really need to start taking things you say with
> > a lot more salt.
>
> and pepper. Seriously, I stand by what I said on reordering.
>
> [...]
> > That's just opinion or wishful thinking. While java may allow
> > movement into a locked critical region, it's undefined for
> > Posix threads.
>
> Undefined includes "may allow". What's your problem?
>

Saying "Posix allows" implies that somewhere buried in the Posix
spec is an explicit statement to that effect. There's no such
thing. If fact, since Posix has no formal memory model, you have
to be rather vague about saying what Posix pthreads actually does and does
not do. That's why I was suprised when these statements were
first made. It seemed strange for Posix to be saying things that were
based on a specific formal memory model when Posix never stated
what the memory model was in the first place.

Joe Seigh

Alexander Terekhov

7/30/2004 4:17:00 PM

0


Joe Seigh wrote:
[...]
> Saying "Posix allows" implies that somewhere buried in the Posix
> spec is an explicit statement to that effect.

POSIX is a contract. (And the GPL is not ;-) ). If the contract
doesn't say that "this is not allowed" (imposing restriction)
then it is allowed.

regards,
alexander.

--
http://terekhov.de/GPL'ed-S...

David Holmes

8/2/2004 7:08:00 AM

0

"Joe Seigh" <jseigh_01@xemaps.com> wrote in message
news:410A4FB8.AEC1157A@xemaps.com...
> Nick Maclaren wrote:
> >
> > In article <410A44FF.8E914EE7@xemaps.com>,
> > Joe Seigh <jseigh_01@xemaps.com> writes:
> > |>
> > |> POSIX has a Posix Compliance specification that applies separately
from
> > |> the C standard. Among other things, it allows statements to be moved
> > |> into a locks critical sections, but not out. ...
> >
> > Well, you might be right. However, since I am a suspicious person,
> > and have some reason to believe that you are imagining things, can
> > you provide a precise reference? Preferably an IEEE publication
> > number, but anything checkable will do.
> >
>
> Well, I don't have a copy of the Posix standard but somebody in c.p.t.
> can give you the reference. Cross posting to c.p.t.

Having come across "a conforming POSIX compiler won't do that" in the course
of many discussions in c.p.t over the years, it is easy to think that the
standard says some things more explicily than it actually does. The
prohibitions on code motion are not so much hard and fast rules for "correct
synchronization" by the compiler, but rather how (in part) the compiler can
meet its POSIX obligations. Those obligations are simply stated but have
deep and sometimes unclear implications. If moving code into a critical
section does not break any of POSIX's rules concerning synchronization then
the compiler is allowed to do it. The problem is the rules for
synchronization don't make it clear what actions would, or would not break
them.

David Holmes