topic proposal: differences/changes when you move to multithread

Forum for discussion about the documentation project.
fxm
Posts: 8957
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: topic proposal: differences/changes when you move to multithread

Postby fxm » Mar 25, 2019 16:38

How to use console statements and keyboard inputs with multi-threading?

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)

[edit]
DONE:
post #11: How to use console statements and keyboard inputs with multi-threading?
Tourist Trap
Posts: 2756
Joined: Jun 02, 2015 16:24

Re: topic proposal: differences/changes when you move to multithread

Postby Tourist Trap » Mar 26, 2019 19:16


Impressive work on a difficult topic. This last chapter is very interesting.
I have a little question close to the topic. What is the difference between a process and a thread. Can I somehow solve lockdowns by running independent processes synchronised by any way, rather than threads (if they differ)?
fxm
Posts: 8957
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: topic proposal: differences/changes when you move to multithread

Postby fxm » Mar 26, 2019 20:17

See for example at https://www.tutorialspoint.com/differen ... and-thread

I propose to add the following at the beginning of the first post of my article:
What is the difference between a thread and a process?

Process:
- Intuitively, a process is nothing more than the program placed in memory or running with all the run-time environment (or all the resources) associated with it.
- In other words, when your program is located on the hard disk of your machine it is always a program or a simple application, but once executed (or placed in memory) a set of resources (amount of memory space occupied, used processor registers and its status, the owner of the process, the permitted operations, ...) is assigned to it and it simply changes its name. It becomes a process.
- So to simplify, process rhymes with program running.

Thread:
- A thread is a portion or part of the process and the smallest sequential unit of instructions processed independently by the scheduler of the operating system.
- It is simply an execution or processing unit composed of a set of instructions contained in the process. See it as the smallest task or operation within the process that is manageable by the scheduler.
- A thread shares information such as a data segment, a code segment, ..., with its peer threads spawned by the same base-thread (see below in post), while it contains its own registers, stack, ....
- Obviously, a process can be composed of one or more threads, everything will depend on the programmer. In the case of a single-threaded process we speak of single-threading, in the opposite case of multi-threading.
[edit]
DONE
post #1
Tourist Trap
Posts: 2756
Joined: Jun 02, 2015 16:24

Re: topic proposal: differences/changes when you move to multithread

Postby Tourist Trap » Mar 28, 2019 1:55

Thanks again fxm.

I still have a more subtle question about the basic definitions of process and thread..
The OS is a ever running program. Are the other running programs, processes, or threads, relative to the OS?
Or we can't compare at all?
My suspicion is that process = thread if the thread is inside a program that makes some deep ressource management. I may of course be totally wrong, don't know.
fxm
Posts: 8957
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: topic proposal: differences/changes when you move to multithread

Postby fxm » Mar 28, 2019 6:09


Return to “Documentation”

Who is online

Users browsing this forum: No registered users and 2 guests