Bus or Alse


#1

Hi its a mixed and complicated question.
Now i got a game processes and objects ,and i got a suspect that some of them might get called and modified by several sources at a time .My question is what and how should i use to manage this,is there any bus function implemented in JME or other things you could suggest ? any suggestion is wellcome :slight_smile:

For example ,lets say i got a soldier with its AI that doing a thing ,and then arrive player and hit him,lets say they are in different treads and in different cores .I migt be a bit confused as allways but … :smiley:


#2

What?


#3

What you intend with “What” ?
My question is how to manage several process accessing same object at a same time


#4

Don’t?

Use an ES?

Be more specific?


#5

ES ? what is ES ?
Lets say i have class Soldier and 100 objects :soldier1,soldier2 and soo on.
Lets say i say treadOne move this guys forward 1 step each frame.
Lets say i have other thread threadTwo that manages player,player arrive at soldier and hit him,same time as threadOne moves him forward. threadTwo says stay and die,threadOne says go gorward.
I need to lock object and its data soo only one tread at time can change it.and other one cant open it at a same time

Some thing like this https://docs.oracle.com/javase/tutorial/essential/concurrency/newlocks.html


#6

This would cause you to get an error due to updating the scene graph from another thread, if I understand what you’re saying correctly , so you would want to look into how to use multithreading with monkey https://wiki.jmonkeyengine.org/jme3/advanced/multithreading.html

Although for 100 soldiers you shouldn’t necessarily need to use multithreading, but I suppose it depends on how complex your ai is


#7

Entity System. Also known as “Entity Component System”.

It’s precisely for managing the types of things you are talking about but there is a learning curve involved. Though it’s probably a less painful one than using threads for the first time without knowing anything about it. Sort of like juggling chainsaws when you don’t know how to juggle yet.


#8

Note that it can be very slow.


#9

A threading design that relies heavily on synchronized is probably a broken design. There are almost always much better ways… and synchronized is no silver bullet. It can get you into a lot of trouble if you don’t know what you are doing. (Though fortunately modern JVMs are very good at pointing out your deadlocks for you…)