"Hi,
We need an advertising space with do-follow links on your blog
savannah.gnu.org.
• We provide 500+ words
• no copy article
• the duration will be a minimum of 1 year
Can you please write to us if possible to place an article with a link
leading to betting related site and how much it wi
> in that the optimization can take place in a loop, if somewhere after
> the loop the memory location is unconditionally written.
OK, thanks for the description, I just couldn't build GCC after update
to see what result looks like. And big Thank You for the patch!
--
Tomash Brechko
On Tue, Oct 30, 2007 at 07:50:04 -0700, Ian Lance Taylor wrote:
> Tomash Brechko <[EMAIL PROTECTED]> writes:
>
> > Even if we put aside the fact that there's no such membarrier()
> > equivalent in POSIX bindings, this won't help.
>
> In POSIX, any m
On Tue, Oct 30, 2007 at 15:33:56 +0100, Eric Botcazou wrote:
> We're not talking about locks, see the example you gave in your
> first message.
Please read the _description_ that comes along with the code example.
Anyways, the patch is there.
--
Tomash Brechko
n lock() and
unlock(). When condition is false, any speculative store to *p is
bogus, because any condition is potentially a 'lock acquired'
condition (or 'not read-only' condition). And it was shown that the
volatile qualifier can't be applied in general case.
But perhaps I'm the only one who is still unsure about the outcome of
this discussion :).
--
Tomash Brechko
data to any function without casting away the
qualifier.
volatile can be properly used _only_ if you also assume atomicity and
cache-coherence, and this is beyond POSIX. But anyway, I'm proving
the opposite: when you use POSIX locks, you don't have to use
volatile, that it.
--
Tomash Brechko
On Tue, Oct 30, 2007 at 10:59:24 +0300, Tomash Brechko wrote:
> On Tue, Oct 30, 2007 at 08:56:08 +0100, Eric Botcazou wrote:
> > > The use doesn't become proper simply because it appears in the code,
> > > even if in the code of GCC. volatile might be used there for
rpose.
Then you could remove it, if not for unlocked access.
--
Tomash Brechko
I accidentally removed the essential line, it should be:
On Tue, Oct 30, 2007 at 10:44:52 +0300, Tomash Brechko wrote:
> static volatile int __gthread_active = -1;
>
> ...
int __gthread_active_latest_value = __gthread_active;
> /* This test is not protected to avoid t
system will indeed give you
the correct result, but such use is not POSIX-compliant, and I mostly
talk about POSIX Threads.
--
Tomash Brechko
must be a store).
Thank you! I almost started to think like I'm loosing grounds for my
claims :).
--
Tomash Brechko
r cases won't affect performance of pointer case.
--
Tomash Brechko
On Mon, Oct 29, 2007 at 19:20:25 +0300, Tomash Brechko wrote:
> Good reasoning, and that's exactly what some of us are asking for.
> Please see the example:
At higher optimization levels GCC may inline f(), or not call it at
all, so below is a more complete case:
#include
#includ
oonlight:/tmp$ ./mmap
Segmentation fault
:-/
The discussion is not pointless, just please try to understand what
other people are trying to say. No one is stupid, we all just not on
the same page yet.
--
Tomash Brechko
x27;t think it is that unrealistic.
Thanks. I had to change %Lu to %lu, and the example shows the point
when run multiple times.
--
Tomash Brechko
On Mon, Oct 29, 2007 at 12:04:14 +0300, Tomash Brechko wrote:
> Rather, "...before it released the mutex, and we acuired the same
> mutex". But it may be the same thread actually, so "final value" is
> the value that is seen by the thread at the beginning of excusiv
On Mon, Oct 29, 2007 at 11:55:25 +0300, Tomash Brechko wrote:
> OK, formally there's no "final" value from current thread's POV, only
> the "current" value. "Final" only matters from other thread's POV,
> like "this is the last value t
thread's POV, only
the "current" value. "Final" only matters from other thread's POV,
like "this is the last value that was produced by another thread
before it released the mutex".
But shouldn't we formally define "define" first? :)
--
Tomash Brechko
On Mon, Oct 29, 2007 at 11:42:10 +0300, Tomash Brechko wrote:
> It means that the current thread is free to cache the value in the
> register as long as it knows no other thread can access it (i.e. as
> long as it holds corresponding mutex).
And because your next question will be
thread is free to cache the value in the
register as long as it knows no other thread can access it (i.e. as
long as it holds corresponding mutex).
--
Tomash Brechko
On Mon, Oct 29, 2007 at 09:12:09 +0100, Eric Botcazou wrote:
> Define "final value".
The value that will be seen by other threads after they synchronize
memory (with pthread_mutex_lock(), for instance).
--
Tomash Brechko
On Mon, Oct 29, 2007 at 01:08:22 -0700, Andrew Pinski wrote:
> On 10/29/07, Tomash Brechko <[EMAIL PROTECTED]> wrote:
> > But if *v is simply shared, do all stores to it matter? No, only the
> > final value is relevant.
>
> Actually it depends, it might matter. If y
On Mon, Oct 29, 2007 at 10:43:13 +0300, Tomash Brechko wrote:
> I think most pro-volatile people didn't understood the meaning of
> several papers in the Internet that say you have to use volatile.
And some don't understand the true purposes of volatile itself. In
the code below
On Mon, Oct 29, 2007 at 02:39:15 -, Dave Korn wrote:
> BTW, you and Tomash should get your stories in synch. He says speculative
> loads are ok, just no stores, and wants a kind of half-volatile flag that
> would only suppress stores. I think you're already looking one step
On Sun, Oct 28, 2007 at 21:03:09 +0300, Tomash Brechko wrote:
> What I was trying to say, is that it would be nice to have
> -fno-thread-unsafe-optimization option.
Rather clear -fno-speculative-store, in the light of mprotect() and
non-writable memory.
--
Tomash Brechko
as I understood this discussion, there will be such option in GCC
in the nearest future.
--
Tomash Brechko
ug_ in languages that define memory
semantics (Ada, Java), and no one yet argues that GCC should be fixed
wrt to only those languages.
--
Tomash Brechko
x27;s also explicit unconditional store), without the need
to analize whether it is safe or not.
--
Tomash Brechko
u mean here. If extern vs static---that's
of no concern. What matters is whether the object can possibly be
accessed from another thread, and this has nothing specific to C++.
--
Tomash Brechko
On Fri, Oct 26, 2007 at 21:45:03 +0400, Tomash Brechko wrote:
> Note that it doesn't cancel cmoves, as those are loads, not stores.
I just checked with x86 instruction reference, CMOVcc is reg->reg or
mem->reg, never reg->mem. You know God's deed when you see it. :)
--
Tomash Brechko
ll));
void
g(int set_v, int *v)
{
if (set_v)
*v = 1;
}
Please note that I'm not trying to prove you wrong, just curious about
the reasons why there's no optimization.
--
Tomash Brechko
ction, should be treated specially. Also, for the case
void
f(int set_v, int *v)
{
if (set_v)
*v = 1;
}
there's no load-maybe_update-store optimization, so there won't be
slowdown for such cases also (BTW, how this case is different from
when v is global?).
--
Tomash Brechko
rked as such explicitly by
the programmer, or is it a compiler job to identify them?
--
Tomash Brechko
ion.
Cheers,
--
Tomash Brechko
itself.
Still, "let's wait and see" is probably the best outcome that I can
expect from this discussion, so thanks anyway. ;)
--
Tomash Brechko
some ad-hoc gcc-specific
> proposal.
Aha, but repeating worked. This is the first time someone agrees that
the problem lies not entirely in the programmer's code. Thank you!
:))
--
Tomash Brechko
every shared data in every threaded program be defined volatile, just
for the case? I never seen latter approach in any Open Source project
(though didn't look for it specifically), and many of them are
considered quite portable.
Again, we are not discussing some particular code sample, and how it
might be fixed, but the problem in general. Should GCC do
thread-unsafe optimizations, or not?
--
Tomash Brechko
. Making all shared objects
volatile is an overkill, and is more a trick rather than a solution.
--
Tomash Brechko
r if x >= 99.
--
Tomash Brechko
asic blocks that have stores, GCC
shouldn't add any.
--
Tomash Brechko
already
> there.
Why? For that example, if executed verbatim, it is either i > x
always false, or the mutex is properly acquired. No one is assuming
atomic update.
--
Tomash Brechko
On Mon, Oct 22, 2007 at 11:54:47 +0100, Dave Korn wrote:
> http://www.google.com/search?q=Threads+cannot+be+implemented+as+a+library&sour
> ceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org
> .mozilla:en-GB:official
Thanks!
--
Tomash Brechko
On Mon, Oct 22, 2007 at 14:50:44 +0400, Tomash Brechko wrote:
> Can't agree less!
Can't agree more!, that's what it was supposed to say, think you've
got it right ;).
--
Tomash Brechko
why I want
to see Bug#31862 be confirmed, accepted, and fixed.
--
Tomash Brechko
, %esp
movl$mutex, (%esp)
callpthread_mutex_trylock
cmpl$1, %eax; test res
movlacquires_count, %edx; load
adcl$0, %edx; maybe add 1
movl %edx, acquires_count; store
leave
ret
--
Tomash Brechko
to
ensure the same result as some abstract machine (which may be
sequential). In this case the compiler should access the single byte,
no more.
OK, I've got your point, but I'm not satisfied :).
--
Tomash Brechko
xecution path? Or maybe the named bug report is valid
after all?
Thanks in advance,
--
Tomash Brechko
I'm not sure what OpenMP spec says about default data scope (too lazy
to read through), but it seems that examples from
http://kallipolis.com/openmp/2.html assume default(private), while GCC
GOMP defaults to shared. In your case,
#pragma omp parallel for shared(A, row, col)
for (i = k+1; i
48 matches
Mail list logo
