On 2014/10/01 08:56:33, jarin wrote:
On 2014/10/01 08:44:39, marja wrote:
> Clarification: I don't think this can malfunction even if writing the
bool
is
> not atomic, since 1) one thread writes it and one thread reads it 2) the
bool
> only goes from false to true and never back, so even if the reader
thread
reads
> it between the non-atomic write (when the bool contains several bytes:
when
some
> of the bytes have been written and some not), it'll get whatever value,
but
it
> will get the correct value when it reads it the next time.
>
> IOW, it's a bit sloppy but I guess it should work? LGTM?
not lgtm.
As discussed offline, there should be no data races on normal variables,
i.e.,
variables that are not AtomicWord*. Please use AtomicWord +
Release_Store/Acquire_Load for communication. Otherwise, compiler and
hardware
are allowed to do crazy stuff to your code (and TSan will complain).
In this case, it won't malfunction. The field is written from the main
thread
when the concurrent job is running, and read from the main thread later
when the
concurrent job is done running. The DCHECK guarantees that. The original bug
happened because it was stored on the shared flags_ field which the
concurrent
thread also reads from.
I changed it to atomic ops nevertheless, though imo unnecessary.
https://codereview.chromium.org/616263003/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
