Console statements (such as Locate, Print, Color, ...) and keyboard inputs (such as Inkey, Getkey, Input, ...) are not thread-safe.
Thus when they are used in competing sections of different threads, mutual exclusion is mandatory by means of mutex locking blocks in which in addition code can restore states (such as text cursor position, console color, ...) at end of the block, as they were before (at begin of the block).
But the GetKey or Input keyword cannot be enclosed inside a mutex locking block (as it can be do with the Inkey keyword), because as long as the keyboard input is not completed, the other threads in compete would be fully blocked (waiting for the mutex unlocking).
Therefore, for using Getkey or Input in competing sections of threads:
- Only a single thread (for example, the main thread) can uses Getkey or Input in addition to console statements (such as Locate, Print, Color, ...) and also Inkey, in its competing sections.
- The other threads must not to use in their competing sections any console statement neither any keyboard input keyword, but can use by cons graphics statements (such as Pset, Line, Circle, Draw String, graphic Color, ...) which are themselves thread-safe (they can interlace graphically with the main thread without any problem).
- Input and Getkey exclude the screen locking usage in competing sections of threads (double buffering is recommended as anti-flickering method).
(I intend to add the above as a new post #11 of the "How to Manage a Critical Section of the code of a Thread in FB" article, with examples illustrating specially the specific case of Input usage)
post #11: How to use console statements and keyboard inputs with multi-threading?