Quick Links: Download Gideros Studio | Gideros Documentation | Gideros community chat | DONATE
Semaphores, synchronization, locked during callback functions — Gideros Forum

Semaphores, synchronization, locked during callback functions

kussakovkussakov Member
edited May 2012 in Game & application design

I have a few questions:

1. Is there a way to synchronize things (like semaphores) in Gideros?
E.g. Some way for the code to wait like a millisecond until some callback function is completed.
Like synchronized(something){... some code ...} in objective C...

2. Many physics APIs are locked during callbacks.
What does that mean?
Are they locked while the physics world is doing a "step()"?
Or are they just locked INSIDE a physics callback (like on event Event.POST_SOLVE callback)?
Say I have a game and I want to destroy or add bodies due to some user actions.
Create and destroy body are locked during callbacks...
The user actions a completely outside the physics callbacks. Is this safe?
I am asking because I was doing a test - when the user touches the screen I would add many sprites to the scene + corresponding bodies to the physical world.
Very occasionally there is a sprite that does not move as if the engine could not create and associate a body for it. There are no errors.

3. If you answer to question 2 is "locked during a step()" - then I need some kind of semaphores to synchronize the physics world locked stuff with the users actions and make sure they don't happen while the wold is doing a step (which is happening on Event.ENTER_FRAME by the way).

Since the entire thing works only in callbacks (touches, physics, enter frame, etc.) it will be very hard to work with locked functions without semaphores.
And I can't use global variables for that because the code has to wait...



Likes: r033rt

+1 -1 (+1 / -0 )Share on Facebook


  • MichalMichal Member

    I have a few questions:

    1. Is there a way to synchronize things (like semaphores) in Gideros?
    No, and according to the Lua authors this is "the good thing" (avoiding locks makes the program faster). In Lua you can use coroutines, ar you can pass a function (to be executes) as a callback argument.

    I have no experience with box2d in Gideros, so I will leave this for some else to answer.

  • @Kussakov, I am not sure if this would meet your expectations in terms of the physics engine issues. However for the semphores, have you tried a Lua state machine implementation, that way you have some sort of control and what you want, you can set the states from enterFrame, collisions, etc so in a way it would be what you are after.
    twitter: @ozapps | http://www.oz-apps.com | http://howto.oz-apps.com | http://reviewme.oz-apps.com
    Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
    Cool Vizify Profile at https://www.vizify.com/oz-apps
  • atilimatilim Maintainer
    Box2D functions that alter the physics world are locked during the step function. Box2D does not allow you to alter the physics world inside a callback because you
    might change/destroy objects that Box2D is currently processing.

    I think the best way is buffering your locked processes and applying them just after step function. The other (easy) way is using Timer.delayedCall with delay 0.
  • atilimatilim Maintainer
    edited May 2012
    And here is a simple implementation:
    local toBeDestroyed = {}
    local function onPostSolve(event)
        -- get body to be destroyed
        toBeDestroyed[body] = true    -- I'm not using an array because I want to store a body once
    local function onEnterFrame()
        for body,_ in pairs(toBeDestroyed) do
            toBeDestroyed[body] = nil    -- this is totally valid inside a pairs loop
  • kussakovkussakov Member
    edited May 2012
    Guys thanks for the ideas!

    @Atilim, I already do that(buffer) in my physics callback functions because I knew they were locked.
    I have an array with events that need to happen after the step, but my question was what to do during users actions that are in other places completely separated from the physics callbacks. I was trying to avoid buffering, but I guess I have to rewrite the code to save all complex add body and not so complex destroy body calls and pass them to the physics engine after the step is completed.
    Timer delayed call sounds better. May be you could give me an example. How can I be sure that the delayed call is not executed during a world step()?

    @OZApps, I don't understand how to implement LUA state machine... I will read some more documentation...

    Thanks a lot!

  • An update:
    You know how right after the step() we have a loop to update all graphic objects to match the physical objects (coordinates, rotation)...
    What I did for removing bodies was super simple and safe. I added a flag "remove" to the object.
    In the same update loop I just check the flag and if set I remove the object instead of updating it...

    Adding objects, changing their properties, altering the world properties, etc due to user activity outside the physics engine is totally different matter since the objects and some actions are complex.
    So I am thinking of adding a table with functions and parameter table to be called in a loop after a world step() instead of calling them immediately.
    I don't like it because it is a lot more work and creates complications, but seems to be proper solution and valid for all Gideros physics games when objects need to be added/removed/altered outside of the physics engine due to user activity.
  • kussakovkussakov Member
    edited May 2012
    One last question: What is the exact meaning of "Locked during step()"?
    Does it mean that:
    1. The call will just return without doing anything?
    2. Or it will give an error or stop execution?
    Looks like it is doing 1., but wanted to make sure...

  • atilimatilim Maintainer
    edited May 2012
    It gives an error as "World is locked" and stops the execution.

    What I did for removing bodies was super simple and safe. I added a flag "remove" to the object.
    In the same update loop I just check the flag and if set I remove the object instead of updating it...
    I also think this is the best way.

    But only a small fraction of these functions are locked during step function and they're locked only within the physics events (begin contact, end contact, pre solve and post solve). Therefore it's totally safe to call these functions within any other event (mouse, touch, timer, enter frame, etc)
  • Got it!
    Thanks for the details!
Sign In or Register to comment.