When user selects a position my engine throws an exception when computing pv's for a selected position. Unfortunately this does not happen when playing games (single threaded).
This is probably because my code is not thread safe for it starts a new thread when computing pv's and also the view (helper) creates a new factory when it refreshes the screen.
I don't understand what in the given code is the cause of the bug. So it also might have nothing to do with thread safe code. Perhaps uninitialized data (?). But the given code is executed a million times when playing single threaded games and it never gives an exception.
I can also eliminate code below. Put the result of this code directly in the index. But I don't think that's right.
I don't understand what in the given code is the cause of the bug. So it also might have nothing to do with thread safe code. Perhaps uninitialized data (?). But the given code is executed a million times when playing single threaded games and it never gives an exception.
I can also eliminate code below. Put the result of this code directly in the index. But I don't think that's right.
Henk wrote:and also the view (helper) creates a new factory when it refreshes the screen
Henk wrote:I don't understand what in the given code is the cause of the bug.
Questions:
1) Which kind of exception do you get? What lets you know it is related to the "index" stuff?
2) What do you mean by "creates a new factory"? Usually a factory is something you use to create something else, not something that itself will be created.
3) Which class would be your candidate to make it a "thread safe singleton"? Do you mean "ChessBoardBits"? But currently that isn't even a singleton, it is just something with static data and static methods.
Apart from that, I think you need to ensure that your index tables exist just once in memory, and are properly initialized before being used for the first time. It's simple
Henk wrote:2) I like to have the methods that handle a request to be stateless. If there is no factory (created) nothing can be created.
The more state (variables) the more misery.
But the factory itself will not be "created", it "creates" something else.
I get the impression that you allocate a new piece of memory for your "index" table(s) each time you call PositionFactory(), since InitIndex() does a "new int[64]". If that is the case then I also guess that is not what you intended. Therefore you do not need a "factory" to "create" something that is more like a singleton, for that purpose you normally use an appropriate "getInstance()" method or similar of the singleton class itself. Typically you use a factory to "produce" something that should be produced as often as it is needed.
It is possible that your implementation does most things right regarding all of the above. But in my experience using "unusual" terms often causes trouble.
Smallest change first. Looks like bug has gone. But my engine has more of these non thread safe static variables. Ok position factory should be singleton too.
public static Field GetField(IBoardSquares chessBoard, ulong bitCoord)
{
int i = BitBoardIndex.Instance.Index(bitCoord);
var field = chessBoard[i];
return field;
}
Henk wrote:Smallest change first. Looks like bug has gone. But my engine has more of these non thread safe static variables. Ok position factory should be singleton too.
public static Field GetField(IBoardSquares chessBoard, ulong bitCoord)
{
int i = BitBoardIndex.Instance.Index(bitCoord);
var field = chessBoard[i];
return field;
}
public class ChessBoard: IBoardSquares
{
..
public Field GetField( ulong bitCoord)
{
int i = BitBoardIndex.Instance.Index(bitCoord);
var field = this[i];
Debug.Assert(field.RowNr >= FIRSTROW);
Debug.Assert(field.ColNr >= FIRSTCOLUMN);
Debug.Assert(field.RowNr <= LASTROW);
Debug.Assert(field.ColNr <= LASTCOLUMN);
return field;
}
..
