AI Attack & getSpellAbilityToPlay Timeout

[kevlahnota]

No description provided.

[Hanmac]

@kevlahnota about the AI timeout part, how about separating it into extra Threads per creature?

threadSafeIterable would that change make problems for this ConcurrentModificationException?

When Touching FCollection, how about looking at #3397 ?
Especially looking at SetUniqueList

[kevlahnota]

@kevlahnota about the AI timeout part, how about separating it into extra Threads per creature?

threadSafeIterable would that change make problems for this ConcurrentModificationException?

When Touching FCollection, how about looking at #3397 ? Especially looking at SetUniqueList

I changed the FCollection LinkedList to Lists.newCopyOnWriteArrayList() so it's already thread safe, threadSafeIterable returns the list directly from FCollection, also it uses Sets.newConcurrentHashSet(), (I think this is a shortcut to ConcurrentHashmap.newkeyset).

[Agetian]

I agree with @tool4ever's observations, and after these tweaks it looks like a very useful and nice option! :)

[Hanmac]

I changed the FCollection LinkedList to Lists.newCopyOnWriteArrayList() so it's already thread safe, threadSafeIterable returns the list directly from FCollection, also it uses Sets.newConcurrentHashSet(), (I think this is a shortcut to ConcurrentHashmap.newkeyset).

I just thought we could clean up some code if we make:
FCollection = new SetUniqueList(Lists.newCopyOnWriteArrayList(), Sets.newConcurrentHashSet())

less own code means less errors ;P

[Jetz72]

I changed the FCollection LinkedList to Lists.newCopyOnWriteArrayList() so it's already thread safe

Isn't that going to be a massive hit to performance for a lot of the single-threaded code? CopyOnWriteArrayList really does copy the whole list every time you add or remove list items. Adding a single item goes from O(1) to O(N), and adding iteratively goes from O(M) to O(N * M). Using it for every single FCollection might be excessive.

[kevlahnota]

I changed the FCollection LinkedList to Lists.newCopyOnWriteArrayList() so it's already thread safe

Isn't that going to be a massive hit to performance for a lot of the single-threaded code? CopyOnWriteArrayList really does copy the whole list every time you add or remove list items. Adding a single item goes from O(1) to O(N), and adding iteratively goes from O(M) to O(N * M). Using it for every single FCollection might be excessive.

I did profile it and seems ok so far. I don't know any concurrent list that is available. How does the change react to your machine when using it with lots of token/card generation?

[kevlahnota]

@Hanmac I encountered concurrent modification on Card.class for the Iterable getchangedcardtypes. Is it safe to return ImmutableList.copyOf instead of Iterables.unmodifiableIterable?

[Hanmac]

@Hanmac I encountered concurrent modification on Card.class for the Iterable getchangedcardtypes. Is it safe to return ImmutableList.copyOf instead of Iterables.unmodifiableIterable?

I saw the error too on sentry but I can't explain it yet

Do you got a case to reproduce that?

If yes I could make a short hot fix

[Jetz72]

I replaced the copyonwritearraylist, I think it's slower but its a good tradeoff for those using iterator functions

Seems like a worthy trade-off. Performance is important but I think full support for the collection interface is more important for an implementation this widely used.

[kevlahnota]

@Hanmac @Agetian @tool4ever is there any changes needed? FCollection and ManaPool shouldn't throw ConcurrentModification anymore and seems to work fine.

[tool4ever]

Well my main concern isn't really addressed:
while you might prevent plain out crashing you're still creating race conditions if you allow multiple threads to access the manapool concurrently. Either the floating mana or the arrays for conversion will have a chance of getting messed up. I don't see how you're working around this unless you mark canPlayAndPayFor or something as synchronized.
(And no, I can't give you a fully working example because that's just the nature of nondeterminism)

Also the "dumb check" you had to add clearly hints that something with your custom data alternative doesn't fully work and will break some existing AI behaviour.

[kevlahnota]

Well my main concern isn't really addressed: while you might prevent plain out crashing you're still creating race conditions if you allow multiple threads to access the manapool concurrently. Either the floating mana or the arrays for conversion will have a chance of getting messed up. I don't see how you're working around this unless you mark canPlayAndPayFor or something as synchronized. (And no, I can't give you a fully working example because that's just the nature of nondeterminism)

Also the "dumb check" you had to add clearly hints that something with your custom data alternative doesn't fully work and will break some existing AI behaviour.

Ok I'll revert the Manapool and implement a lock similar to what I did to FCollection and remove the dumb check and restore the sort above it (I still think that's is the cause the of the issue) to satisfy your concern.

[tool4ever]

👍
(I think some parts still look a bit like duct tape but thanks for all the work. And maybe the concurrent SA approach can be reused later for simulation together with normal one, we could talk on Discord in case more AI stuff is on your roadmap)