On 2014/03/24 09:21:31, Michael Starzinger wrote:
The implementation is looking OK and I couldn't spot any bugs in the
lockstep
synchronization. However we are talking about a synchronization mechanism
that
involves four semaphores, one mutex and one atomic variable. This is
impossible
to audit. That poses two concrete concerns about this CL:
- In the current form there are neither use-cases nor test-cases for this
CL.
How did you test it? Is there a concrete use-case you had in mind for this
mechanism?
- How will all of this work once we move to a system that is based on a
job
queue (the thing that Jochen is working on)?
Those are indeed real concerns. I tested this by adding the
SynchronizedScope in
a part of the optimizing phase. However, I wasn't able to construct a test
case
that would reflect that without intrusively change production code.
I'm not sure how the job queue system is going to handle flushing and
stopping,
so I can't tell how well it would fit.
I'm perfectly happy with postponing this until we have to use it at some
point.
https://codereview.chromium.org/177493002/
--
--
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.
