Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Unity jobs and static variables

Discussion in 'Entity Component System' started by RosieGarden, Jun 5, 2018.

  1. RosieGarden

    RosieGarden

    Joined:
    May 4, 2013
    Posts:
    33
    So I understand that reading from global variables from jobs threads is very very bad.

    However, the functions that I want to convert to jobs do a lot of reading from what are essentially global lookup tables that are written to once, before the jobs are started, and never written to again.

    Is there a recommended way to handle something like this? thanks.
     
  2. 5argon

    5argon

    Joined:
    Jun 10, 2013
    Posts:
    1,555
    Copy the lookup table to the job each time the job runs or copy the lookup table to a global static native container, then you can send that to a job with [ReadOnly] then it can act as a link to large memory area outside the job. It might be difficult to manage disposing this way as no system owns it.
     
  3. RosieGarden

    RosieGarden

    Joined:
    May 4, 2013
    Posts:
    33
    Since the lookup table(s) are fixed until program exit, I probably don't have to worry about disposing it.
     
  4. Vuh-Hans

    Vuh-Hans

    Joined:
    Sep 24, 2013
    Posts:
    42
    From what I read somewhere, they will make accessing static variables from inside a job appear as an error in the future. I'm in a similar situation where I have a game database that doesn't change after loading, and lasts until program exit. This database contains things like game object definitions that get compiled from XML/JSON files and a lot of ECS systems need access to.

    What I'm thinking is that if some of the stuff in the static database are structs already, or at least objects that can be easily converted to structs (no reference properties), you can have a DatabaseSystem which creates non-static native hashmaps with struct versions of those objects. Other systems that need the data can [Inject] DatabaseSystem and access the non-static native maps this way.

    If some stuff in your static database can't be easily converted to structs, then things might get trickier. I'm starting to think that to work with ECS, it might be easier to normalize the game's database and make all references between objects use int IDs instead of actual references or strings. Normalizing would mean that objects that have lists as properties would instead have the items of that list as separate objects that reference their parent through ID (similar to SQL tables). This would allow to convert the entire object database into entities/components that reference one another through Entity ID. Once you have your entire database as entities/components inside an ECS world, you can access the data wherever you like without issues, and since everything will access those ComponentArrays<> as [ReadOnly] you won't have problems with job dependencies stalling on them.

    As a note, it might still be a good idea to deallocate native hashmaps when your ECS world gets disposed or stops running. If you go the DatabaseSystem approach, you can deallocate the maps upon StopRunning() or have a MonoBehaviour's OnDestroy() also Dispose() your DatabaseSystem, deallocating there.
     
    Last edited: Jun 6, 2018