I have a question regarding delegates and synchronization. We have an issue with that in our object pooling.
If we have several delegate calls running simultaneously altering a list will be a hazardous. eg.
- Code: Select all
public void CreateDrop(string key, Callback<Drop> successCallback)
{
g.dataManager.GetData(Table.DROPS(), key, delegate(DatabaseObject obj)
{
Drop drop = GetInactiveDrop()
.. set props ...
successCallback(drop);
}
}
public Drop GetInactiveDrop()
{
Drop drop = inactiveDrops[0];
inactiveDrops.removeAt(0);
return drop;
}
In the example above multiple drops might get a reference to the same inactiveDrop since GetInactiveDrop can be called asynchronously.
Now, I talked with a friend that has a bit of experience with threading in Java and he told me about synchronized methods http://download.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html. Which forces the function to be synchronized almost like a transaction.
After a bit of google I found this in C#:
- Code: Select all
[MethodImpl(MethodImplOptions.Synchronized)]
- Code: Select all
public void CreateDrop(string key, Callback<Drop> successCallback)
{
g.dataManager.GetData(Table.DROPS(), key, delegate(DatabaseObject obj)
{
Drop drop = GetInactiveDrop()
.. set props ...
successCallback(drop);
}
}
[MethodImpl(MethodImplOptions.Synchronized)]
public Drop GetInactiveDrop()
{
Drop drop = inactiveDrops[0];
inactiveDrops.removeAt(0);
return drop;
}
Is this the correct way to handle these kind of issues?
Does it have any implications on PlayerIO and server performance?
Is there any different than using lock(this)? eg.
- Code: Select all
public Drop GetInactiveDrop()
{
lock(this)
{
Drop drop = inactiveDrops[0];
inactiveDrops.removeAt(0);
return drop;
}
}
/Thank you for replies :]