Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to reallocate TripleBuffer while running #13

Open
GoogleCodeExporter opened this issue Mar 14, 2015 · 0 comments
Open

Unable to reallocate TripleBuffer while running #13

GoogleCodeExporter opened this issue Mar 14, 2015 · 0 comments

Comments

@GoogleCodeExporter
Copy link

The TripleBuffer can be reallocated / grown prior to running physics and 
rendering. However, once physics and rendering start, reallocating TripleBuffer 
becomes difficult.

The easiest way to reproduce this issue is with the multithreaded example. You 
can modify the code to initially allocate a very small TripleBuffer. Set a 
breakpoint in TripleBuffer::reserve(), then run the simulation. When you hit 
return to fire a ball, you'll encounter the breakpoint and you can step through 
and watch the reallocation.

There are at least two problems with how reallocation is handled:

1. Reallocating doesn't hold any kind of lock. This means a thread (either 
phsics or rendering) could be in the process of obtaining a buffer address at 
the exact moment the reallocation occurs.

2. Even holding a lock would not be sufficient, and here's why: Suppose the 
physics thread gets the write buffer address, then the buffers are reallocated. 
Reallocation copies the old buffer contents to the new buffer, then deletes the 
old buffer. Unfortunately, the physics thread has the address of the (deleted) 
old buffer. This is a dangling pointer.

Not sure how to resolve this issue. Further investigation required.

Original issue reported on code.google.com by [email protected] on 20 Sep 2010 at 8:35

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant