Thread safety when creating objects

[adrian.licuriceanu]

Hello,

After hours of running our custom Unigine scenes streaming, I got a crash in Unigine::ObjectMeshStatic::create (called in a background thread) which I believe is related to data race.

The object is not yet inserted into the scene graph and the call graphs goes as follows:

// My initial code call:
Unigine::ObjectMeshStatic::create(mesh)

From there Unigine goes:

ObjectMeshStatic::ObjectMeshStatic(Mesh &mesh)
    : Object(OBJECT_MESH_STATIC)
    , mesh_render(nullptr)
{

...

void Object::clear_surfaces()

void ObjectMeshStatic::resize_surfaces()

void Object::resize_surfaces()

{
...

    if (has_mesh_managed())
        {
        for (int i = begin; i < end; i++)
            {
-->            surfaces_name[i] = getSurfaceName(i);
            }
        }

    surfaces_size = get_num_surfaces();

    update_lods();
}

Crash place is marked in bold and the error is: 0xC0000005: Access violation reading location

This is release development build, Unigine 2.13

Any idea what may cause this? I was the impression that the entire call stack from above is thread safe. Maybe this is something else?

Kind Regards,
Adrian L.

[silent]

Hi Adrian,

We can't guarantee safe objects creation in a different thread (only main thread should be used for that). To safely operate on these objects (Main-Loop-Dependent Objects) from user threads, you should firstly pause the main loop to avoid interference.

Here is the short article about thread safety in API:

• https://developer.unigine.com/en/docs/2.13/code/fundamentals/thread_safety/

There also might be an issue on the user code, since you have a race condition with a single object (that's really odd).

If you can provide a small reproduction scene it would be interesting to look at.

Thanks!

[adrian.licuriceanu]

Hi,

Yes, it is a strange one, since the mesh and object are unique, used only in this thread, just allocated here locally, not yet inserted in the scene graph. Only thing that I can think of causing this is maybe some inner shared data with other Unigine object (e.g. textures, materials etc). 

Also, putting a lock / unlock pair to encompass any ObjectMeshStatic::create(mesh) in my code, seems to make the bug go away (but of course this crash is happening after hours and hours of streaming, currently the test is in work, fingers crossed it goes well). Also this of course is safe as long as you do this creation from this single point (that there are no other Unigine operations affecting this and not locking with same mutex).

I will look more into this Unigine article. Thank you!

One other point that cleared had to be locked / unlocked was Mesh::crateTangents, which I believe should be thread-safe, but somehow had some crashes for me (I believe in t.tangents.resize(t.normals.size()), something related to mem allocations and race conditions).

Oh, and I would love to share the code/data with you but depends on huge data, needs to be run for hours on specific settings/hardware, and our app is heavily customized (so there are some IP issues involved).

Kind Regards,
Adrian L.

Edited January 29, 2021 by adrian.licuriceanu

[silent]

Yeah, I see. Would hope that adding additional locks will help in that case.