multithreading in different modes

[MeteorTony]

I know we need to handle the serialization for robot vs robot, but I am not sure do we need to handle the serialization for manual vs manual or manual vs robot? If yes, what are the threads controlled by the manual players?

[Troublor]

It doesn't matter whether a player is controlled manually or by a robot. Your handling of multithreading should be agnostic to that.

[Troublor]

ABBAAAAB is OK if AB doesn't happen at the same time?

AB can happen at the same time, as long as the game board ends up in a valid state (see above).

[DelusionArun]

Now I am confused, doesn't only robot have new threads? By that, I mean threads we need to implement/synchronize?

[Troublor]

Yes, technically only robots have threads. But logically, manual control is just like an another thread, making moves concurrently with other players.

[MeteorTony]

Thanks for your elaboration.

For example, suppose we have a game board like this: P..G..p, where P and p are two players. When they concurrently make moves (P goes right and p goes left), it should be impossible that the game board ends up in p.....P. This is an invalid state (violation of serializability property of concurrency) because either order of sequential processing of the two moves will not end up in this state. A valid state could either be Pp..... or .....Pp.

Is there any way to test concurrency like the example mentioned by you?
I set the mean of TimeIntervalGenerator to 1 and ran it several times but basically, I can only check statistics like total diamonds and compare these. How to do testing similar to what you had mentioned above?
Also I don't know if setting the mean of TimeIntervalGenerator to 1 can be considered as concurrent processing of moves...

[Troublor]

Is there any way to test concurrency like the example mentioned by you?

This is actually a research question. There is no easy way to reliably test concurrency bugs. The simplest and probably most effective way is to repeat the execution many times with a small time interval generator, like mentioned in other discussions, #26. For this particular case, you can just create this as a test case and set the assertion as above. In the grading, there is also no rigorous way to soundly test concurrency bugs in your program. What we do is similar to this, setuping corner cases, repeating executions, and checking some assertions. And of course, I cannot tell you all the cases we designed in tests.

Also I don't know if setting the mean of TimeIntervalGenerator to 1 can be considered as concurrent processing of moves...

Programs have delays when executing instructions (due to thread scheduling on CPUs, which is non-deterministic.), if the time interval between moves is similar to the possible delays then the concurrent processing will be exercised when we repeat the execution many times.