Handle overlapping CrossThreadPersistent<> releases.

Handle overlapping CrossThreadPersistent<> releases.

When a CrossThreadPersistent<> is cleared, the associated PersistentNode is
freed. In the case when multiple threads attempt to do such clearing at
the same time, the freeing protocol ensured atomicity but failed to check
if the PersistentNode had been freed already.

This follows up on the freeing of PersistentNodes that r392263 added
for CrossThreadPersistent<>s.

R=haraken
BUG=

Committed: https://crrev.com/be260f5b91027b81be5ba04939ebef2dbd5c92ee
Cr-Commit-Position: refs/heads/master@{#392689}

[sof, 2016-05-10 14:54:41]

Description was changed from

==========
Handle overlapping CrossThreadPersistent<> releases.

When a CrossThreadPersistent<> is cleared, the associated PersistentNode is
freed. In the case when multiple threads attempt to do such clearing at
the same time, the freeing protocol ensured atomicity but failed to check
if the PersistentNode had been freed already.

R=
BUG=
==========

to

==========
Handle overlapping CrossThreadPersistent<> releases.

When a CrossThreadPersistent<> is cleared, the associated PersistentNode is
freed. In the case when multiple threads attempt to do such clearing at
the same time, the freeing protocol ensured atomicity but failed to check
if the PersistentNode had been freed already.

This follows up on the freeing of PersistentNodes that r392263 added
for CrossThreadPersistent<>s.

R=
BUG=
==========

[sof, 2016-05-10 14:59:58]

sigbjornf@opera.com changed reviewers:
+ oilpan-reviews@chromium.org

[sof, 2016-05-10 14:59:58]

please take a look.

[haraken, 2016-05-10 15:21:05]

LGTM, thanks for cleaning up persistent handles a lot!

[sof, 2016-05-10 15:49:56]

Description was changed from

==========
Handle overlapping CrossThreadPersistent<> releases.

When a CrossThreadPersistent<> is cleared, the associated PersistentNode is
freed. In the case when multiple threads attempt to do such clearing at
the same time, the freeing protocol ensured atomicity but failed to check
if the PersistentNode had been freed already.

This follows up on the freeing of PersistentNodes that r392263 added
for CrossThreadPersistent<>s.

R=
BUG=
==========

to

==========
Handle overlapping CrossThreadPersistent<> releases.

When a CrossThreadPersistent<> is cleared, the associated PersistentNode is
freed. In the case when multiple threads attempt to do such clearing at
the same time, the freeing protocol ensured atomicity but failed to check
if the PersistentNode had been freed already.

This follows up on the freeing of PersistentNodes that r392263 added
for CrossThreadPersistent<>s.

R=haraken
BUG=
==========

[sof, 2016-05-10 15:50:05]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2016-05-10 15:50:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1964013002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1964013002/20001

[commit-bot: I haz the power, 2016-05-10 15:58:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-10 15:58:32]

Try jobs failed on following builders:
  win_chromium_x64_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[sof, 2016-05-10 18:38:14]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2016-05-10 18:38:50]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1964013002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1964013002/20001

[commit-bot: I haz the power, 2016-05-10 19:48:44]

Description was changed from

==========
Handle overlapping CrossThreadPersistent<> releases.

When a CrossThreadPersistent<> is cleared, the associated PersistentNode is
freed. In the case when multiple threads attempt to do such clearing at
the same time, the freeing protocol ensured atomicity but failed to check
if the PersistentNode had been freed already.

This follows up on the freeing of PersistentNodes that r392263 added
for CrossThreadPersistent<>s.

R=haraken
BUG=
==========

to

==========
Handle overlapping CrossThreadPersistent<> releases.

When a CrossThreadPersistent<> is cleared, the associated PersistentNode is
freed. In the case when multiple threads attempt to do such clearing at
the same time, the freeing protocol ensured atomicity but failed to check
if the PersistentNode had been freed already.

This follows up on the freeing of PersistentNodes that r392263 added
for CrossThreadPersistent<>s.

R=haraken
BUG=
==========

[commit-bot: I haz the power, 2016-05-10 19:48:45]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-05-10 19:50:12]

Description was changed from

==========
Handle overlapping CrossThreadPersistent<> releases.

When a CrossThreadPersistent<> is cleared, the associated PersistentNode is
freed. In the case when multiple threads attempt to do such clearing at
the same time, the freeing protocol ensured atomicity but failed to check
if the PersistentNode had been freed already.

This follows up on the freeing of PersistentNodes that r392263 added
for CrossThreadPersistent<>s.

R=haraken
BUG=
==========

to

==========
Handle overlapping CrossThreadPersistent<> releases.

When a CrossThreadPersistent<> is cleared, the associated PersistentNode is
freed. In the case when multiple threads attempt to do such clearing at
the same time, the freeing protocol ensured atomicity but failed to check
if the PersistentNode had been freed already.

This follows up on the freeing of PersistentNodes that r392263 added
for CrossThreadPersistent<>s.

R=haraken
BUG=

Committed: https://crrev.com/be260f5b91027b81be5ba04939ebef2dbd5c92ee
Cr-Commit-Position: refs/heads/master@{#392689}
==========

[commit-bot: I haz the power, 2016-05-10 19:50:13]

Patchset 2 (id:??) landed as
https://crrev.com/be260f5b91027b81be5ba04939ebef2dbd5c92ee
Cr-Commit-Position: refs/heads/master@{#392689}

[sof, 2016-05-11 06:52:01]

On 2016/05/10 15:21:05, haraken wrote:
> LGTM, thanks for cleaning up persistent handles a lot!

It looks they're in a good state, for now.