Eschecs FreeBASIC (UCI chess GUI)

[Roland Chastain]

I added more debug code. Here is a screenshot of the application after it has frozen, with the console behind.
Screenshot

So the program seems to crash somewhere here:

Code: Select all

' graphics.bi
sub TMovingChessImage.MoveTo(byval aX as integer, byval aY as integer)
  '...
  do
    sx += dx
    sy -= dy
    screenlock
    img.Redraw(sx, sy)
    screenunlock
    sleep(20, 1)
  loop until (sx = XToScreen(fX)) and (sy = YToScreen(fY))
#endif
  DEBUG_LOG("<- MoveTo")
end sub

[badidea]

Is it possible that a AI 'solver' runs in parallel with the animation? And that not the animation is the problem but the AI?

[Roland Chastain]

Is it possible that a AI 'solver' runs in parallel with the animation? And that not the animation is the problem but the AI?

Yes, I was thinking of that. The dialog with the engine is made in a separate thread. Maybe there is something wrong with the thread. Maybe I did something wrong in the thread management...

Code: Select all

' eschecs.bas
type TListener
  dim handle as any ptr = 0
  dim sync as any ptr = 0
  dim quit as boolean = false
  dim pause as boolean = true
  dim procedure as sub (aOutput as const string) = 0
end type
' ...
dim shared listener as TListener ptr
listener = new TListener
listener->sync = mutexcreate
listener->procedure = @OnOutput
listener->handle = threadcreate(@ProcedureThread, listener)

I will try some human versus human games to see what happens.

[Roland Chastain]

In fact, the problem is certainly not in the animation. If I disable animation, the problems still happens.

Maybe is the following code bad?

Code: Select all

sub ProcedureThread(byval param as any ptr)
  DEBUG_LOG("")
  dim engineOutput as string
  with *cast(TListener ptr, param)
    do
      sleep(20)
      if .pause then continue do ' <---
      engineOutput = ReadEngineOutput
      if len(engineOutput) > 0 then
        mutexlock(.sync)
        .procedure(engineOutput)
        mutexunlock(.sync)
      end if
    loop until .quit
  end with
end sub

This probably isn't the good method to pause the thread...

[badidea]

I think that the TMovingChessImage.MoveTo() set one or more variables that are used by the AI. Without the animation the problem does not seem to occur because TMovingChessImage.MoveTo() is faster in this case. The AI uses the where() array I expect? Also with faster animation (sleep 1, step 10) the problem does not (or not quickly) occur.

It is difficult for me to understand what happens where, but what I see, in what I think is that main loop, is:

Code: Select all

  /'
  if not graph.animationDone then
    chessboard.Animate
    continue do
  end if
  '/

Should that not be enabled? While doing animation don't do anything else?

[fxm]

I don't have enough code to check for thread safety, but can you try replacing 'Sleep(20)' with 'Sleep(20, 1)', and do this the same ('Sleep(x, 1)' instead of 'Sleep(x)'or 'Sleep(x, 0)') everywhere where there may be a conflict between the threads.

[edit]
Typo corrected: 'Sleep x, 1' instead of 'Sleep x' or 'Sleep x, 0'

[Roland Chastain]

Thank you fxm, I will try that.

[fxm]

See Programmer's Guide / Multi-Threading / Critical Sections FAQ / 10. Is it better to take precautions when using the keyword 'Sleep' in threads?

[Roland Chastain]

It is difficult for me to understand what happens where, but what I see, in what I think is that main loop, is:

Code: Select all

  /'
  if not graph.animationDone then
    chessboard.Animate
    continue do
  end if
  '/

Should that not be enabled? While doing animation don't do anything else?

It's some code that I wrote when I tried to remake the animation procedure. Maybe indeed I should give it another try, because meanwhile I discovered something that I didn't know about the parameter of xSleep.

Code: Select all

do
  event->xSleep(1)
  /'
  if not graph.animationDone then
    chessboard.Animate
    continue do
  end if
  '/

I think that the TMovingChessImage.MoveTo() set one or more variables that are used by the AI. Without the animation the problem does not seem to occur because TMovingChessImage.MoveTo() is faster in this case. The AI uses the where() array I expect? Also with faster animation (sleep 1, step 10) the problem does not (or not quickly) occur.

The graphical functions and the AI use different variables. But it's true that the problem always occurs during a computer move, never during a user move...

[Roland Chastain]

I tried to put Sleep x, 1 everywhere, even in sGUI, where there is a Sleep 1. It doesn't seem to solve the problem.

The weird thing is that the program begins to work correctly. It would be more easy to understand if it wouldn't work at all.

Maybe I will rewrite a simpler version of the program, without using sGUI. Maybe that way we will see something...

[fxm]

In addition to using mutexes (that I saw in your snippets), do you also use conditional variables (with CondCreate, ...) ?

[fxm]

Otherwise another classic trap (I saw you are using [ScreenLock ... ScreenUnlock] and sGUI which maybe uses screen locking?)

All input keywords (like for keyboard, mouse) cannot be safely run when the screen is locked.
So a such keyword must be outside of any [Screenlock...Screenunlock] block:
- outside such a block in its own thread (including the main thread),
- and protected of such a block of another thread (including the main thread) by a 'Mutex'.

One thread:
.....
MutexLock(same_id)
s = Inkey
MutexUnlock(same_id)
.....

Other thread:
.....
MutexLock(same_id)
ScreenLock
.....
ScreenUnlock
MutexUnlock(same_id)
.....

For more information around all this, see in Programmer's Guide / Multi-Threading / Critical Sections FAQ:
- 6. How to use 'Screenlock' with multi-threading?
- 7. How to use 'video paging (double buffering or page flipping)' with multi-threading?
- 8. How to use the FB runtime library for multi-threaded applications (gfxlib2) with multi-threading?
- 9. How to use console statements and keyboard inputs with multi-threading?

[Roland Chastain]

Thank you fxm. I will study all that.

Today I tested compilation under Windows. I fixed small things relative to line endings. If you or someone would want to take a look, the code is still at the same place: eschecs.zip

[Roland Chastain]

Otherwise another classic trap (I saw you are using [ScreenLock ... ScreenUnlock] and sGUI which maybe uses screen locking?)

All input keywords (like for keyboard, mouse) cannot be safely run when the screen is locked.

Indeed sGUI uses screen locking. But it seems that the problem doesn't come from that: I tried to remove all screenlock-screenunlock from the project (including sGUI), and the problem is still here.

[Roland Chastain]

Could the problem come from here?

Code: Select all

' sgui_systemevents.bas
function GetSysEvents(XButton as integer) as integer  
  ' ...
  KEY=inkey
  
  ScreenEventExists=1
  do
    if (ScreenEvent(@SEvent)) then