esult in loosing the optimisation) to make it generally safe.
Steven
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Brian Hurt
Sent: Saturday, 9 April 2005 6:07 AM
To: openssl-dev@openssl.org
Cc: [EMAIL PROTECTED]
Subject: RE: OpenSSL use of DCLP may not be
On Fri, 8 Apr 2005, David Schwartz wrote:
Right, and the standard doesnt require them to. Nor does it require
them
to perform the operations in order as seen by another processor.
OK- my apologies. I was misreading what you were saying. We're on the
same page.
Right, and Im arguing
> On Fri, 8 Apr 2005, David Schwartz wrote:
> > No. The C standard is not telling the compiler what to do.
> > It is saying
> > what the system must do when it runs the particular source code. If the
> > compiler cannot generate code that makes the system as a whole
> > comply with
> > the standa
On Fri, 8 Apr 2005, David Schwartz wrote:
No. The C standard is not telling the compiler what to do. It is saying
what the system must do when it runs the particular source code. If the
compiler cannot generate code that makes the system as a whole comply with
the standard, then the compil
> On Thursday 07 April 2005 19:09, David Schwartz wrote:
> > > Translation: The compiler can't make assumptions about the state of a
> > > variable marked "volatile", and MUST generate code that writes
> > > every result
> > > stored there as well as code that reads the variable EVERY
> > > SING
and the
restrictions imposed on it in relation to accesses to the same memory
address.
Regards,
Steven
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Jim Schneider
Sent: Saturday, 9 April 2005 12:08 AM
To: openssl-dev@openssl.org
Subject: Re: OpenSSL us
I appologize if this gets posted twice - we've recently changed email
addresses company-wide, and my old address is the one that's subscribed to
openssl-dev.
On Thursday 07 April 2005 19:09, David Schwartz wrote:
> > Translation: The compiler can't make assumptions about the state of a
> > vari
odern MP systems that is rarely the case.
Regards,
Steven
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Jim Schneider
Sent: Friday, 8 April 2005 7:35 AM
To: openssl-dev@openssl.org
Subject: Re: OpenSSL use of DCLP may not be thread-safe on multiple
pro
> On Thursday 07 April 2005 16:39, David Schwartz wrote:
> A bit off-topic, but...
> > If you mean 'volatile', no, that doesn't do anything. Specifically,
> > 'volatile' has no special semantics for multi-processors. There may be
> > specific compilers where it has such semantics, but the st
On Thursday 07 April 2005 16:39, David Schwartz wrote:
A bit off-topic, but...
> If you mean 'volatile', no, that doesn't do anything. Specifically,
> 'volatile' has no special semantics for multi-processors. There may be
> specific compilers where it has such semantics, but the standard doe
> It strikes me that the H/W designers have played a bit "fast and
> loose" with
> the cache consistency issue here
For the vast majority of cases, this is a pure speed boost. For the tiny
number of cases where it causes a problem, you use mutexes.
> - I believe I understand the C/C++
>
ssage-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of David C. Partridge
Sent: Thursday, 7 April 2005 6:17 PM
To: openssl-dev@openssl.org
Subject: RE: OpenSSL use of DCLP may not be thread-safe on multiple
processors
Thanks all.
It strikes me that the H/W designers have played a bit
Thanks all.
It strikes me that the H/W designers have played a bit "fast and loose" with
the cache consistency issue here - I believe I understand the C/C++
optimisation issues, and these CAN be worked around (IMHO) within the rules
of the standard by using bool in some cases.
However I've notifi
> Since aquiring the mutex is already on the 'slow' track,
> couldn't you
> just aquire a second (pointless) mutex inside the first around only the
> 'initialized=1;' assignment? If mutexes resolve the initial situation
> then they must be implemented with a memory fence (in the itanium
> model),
David Schwartz wrote:
I mean that if the order of memory write visibility between
processors can't
be g'teed, than a whole lot MORE than just DCLP crashes and burns ... How
in that case can anyone write safe MP code?
D.
The only correct and safe way to do it is with mutexes or their
equ
> I mean that if the order of memory write visibility between
> processors can't
> be g'teed, than a whole lot MORE than just DCLP crashes and burns ... How
> in that case can anyone write safe MP code?
>
> D.
The only correct and safe way to do it is with mutexes or their
equivalent.
D
use locks can be thread-unsafe it can be
even more thread-unsafe when reordering is involved.
Regards,
Steven
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of David C. Partridge
Sent: Thursday, 7 April 2005 12:56 AM
To: openssl-dev@openssl.org
Subject: RE: Open
ARGH!
Are you absolutely sure that this is the case - that's scary - I thought
that the whole issue of SMP cache coherency and write order was solved years
ago.
I mean that if the order of memory write visibility between processors can't
be g'teed, than a whole lot MORE than just DCLP cra
preserved and the Itanium is a good example of this.
Regards,
Steven
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of David C. Partridge
Sent: Wednesday, 6 April 2005 11:08 PM
To: openssl-dev@openssl.org
Cc: [EMAIL PROTECTED]
Subject: RE: OpenSSL use of DCLP
]
Subject: RE: OpenSSL use of DCLP may not be thread-safe on multiple
processors
I've just read the paper, and I believe that the following variation on
the code would work and would avoid the MP unsafe issues raised because
bool is defined to be a single byte.
Further-more, I'm pretty certa
I've just read the paper, and I believe that the following variation on
the code would work and would avoid the MP unsafe issues raised because
bool is defined to be a single byte.
Further-more, I'm pretty certain that it also resolves the issues with the
order of construction
and setting of the p
21 matches
Mail list logo