topic proposal: differences/changes when you move to multithread

Forum for discussion about the documentation project.
Posts: 287
Joined: Nov 28, 2012 1:27
Location: California

topic proposal: differences/changes when you move to multithread

Postby speedfixer » Jun 22, 2018 19:27

Everyone WANTS to do it, but the learning curve seems too steep.
Using multithreading(MT) is certainly a different way to think, and can be a very difficult concept to correctly appreciate the changes needed.

Once simple code can seem to get 10 times more complicated. Many objections always thrown out about why NOT ... just ... aren't ... true.
(My biggest gripe: you only have 2 cores? Then MT won't help you. Then tell me this: how did we have all those single core, multiuser systems way back when? I sold a LOT of them! My customers were happy.)

What would help:
Better discussions of when and when not to use MT would help, not just parroting the usual textbook stuff. One discussion of when (for example. simply: you have enough speed and resources available); one discussion of when not (with todays systems, you HAVE to test to know); one discussion of the tradeoffs (complexity of code, halted processes, debugging, future scope/intent of the program/library you are writing), and more.

With any code examples held to the end, a practical discussion of what changes might be needed from single thread code to MT code. (I am seeing the 'by ref' discussion and hope the tutorial will at least touch on the changes most likely needed for MT.)

Actually, it isn't that hard once you appreciate then *when* as well as the *what* of your code.
I had/still have more trouble with remembering to update pointers than I do with code/data guards.

Especially on this topic, I know a few of the pros out there have to work hard to keep their mouth shut without inviting a firestorm or shutdown from a few of the high contributers. I don't know how to avoid that.

Eveyone runs into problems with user input and screen display. Each could be a seperate (but obviously related) topic.
Loop control (whether main controlling thread, or thread controlling main - actually, it MUST be both) is mentioned in forums, but not well treated.

While FreeBASIC can and should be simple for a beginner to learn, Its advanced features and speed allow for truely powerful programs. The tutorials should help everyone get there quicker. (And PLEASE: clear out/refresh some the very old, very stale, only barely correct old tutorials that new people look to and still can't get beyond what they knew *before* they looked at those old things. And empty still-under-contruction time wasteing links/topics.)

But I DO want FB programmers to be able to write pro-level programs. FB is capable of that. (Then, we can move to improving portablility, maybe. A topic on library inclusions for the different OS's? Maybe a seperate forum topic on required support libraries, how to acquire or avoid them? Windows is either a blessing or a curse with its 'all MS, all the time' approach.)

I REALLY like this more organized approach shown lately. I am grateful fxm has the time, energy, and interest to invest himself in writing these documents. I believe these will help move FB forward better AT THIS TIME than more compiler/system changes.

Tourist Trap
Posts: 2614
Joined: Jun 02, 2015 16:24

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

Postby Tourist Trap » Jun 22, 2018 22:42

Hi here,

not sure I'm not off-topic. If I'm so, please excuse me. So if not wrong about the place, I wanted to reference here a discussion we had long time ago dealing with multithreading with graphics. Here is some of what was said (by me)...
As a peasant, this is here what I need to know:

Can we do multithreading in FB? ---------->
  • yes it's an easy syntax based on THREADCREATE and a procedure with an inner loop ,
  • but not all commands, actions, keywords, etc... are avaiable without mutual exclusion mechanism

Can we do multithreading with graphics actions? ---------->
  • yes, but many commands are to be mutexed for many reasons, and some should be avoided for other reasons like flickering

What strategy suggested for multithreading graphics ? ----------->
  • using the main program with a main loop,
  • having the screen actualized once and once only in the whole loop cycle, including threads
  • having the main loop do the screen actualization, and the threads synchronisation, conditional call, or whatever control and management
  • for doing this, ScreenCopy strategy is ok with some synchrozitation via a waiter mechanism, or a CONDSIGNAL mechanism
  • ScreenLock/ScreenUnlock (good in general for single threading) is not to be priviledged here: each time ScreenUnlock is triggered the screen has to be refreshed and can cause flickering

What is cool with multithreading graphics ? ----------->
[list][*]each thread can set an active screen of its own with SCREENSET, and also have one VIEWPORT, there is no conflict at this level, that's quite manageable

Of course it's perfectly unclear. It's not that simple to write an article!

Whole reference:

Lost Zergling
Posts: 161
Joined: Dec 02, 2011 22:51
Location: France

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

Postby Lost Zergling » Sep 09, 2018 23:42

I carried out in May June some tests on the lists using Mutex. I had to stop this way because of excessive performance decreases regardless of the method used. Maybe my programming was hugly and/or the multi threading was the best choice in this context. I would do other tests after enough progress on the multi threading but it seems that the OS shares the time allocated to the various programs, thus the main instance seems significantly slowed compared to two compiled code manually launched one after the other by the user or launched by a batch and interacting with each other in another way. Moreover, the control of threads also seems to consume the global resource : as a result, the program seems hardly faster in return for a huge complexity while mobilizing significantly more global resources. My point is not to criticize, I think that multi threading is very useful, but in the context of the list engine, I can not (yet?) validate the interest of doing it.
Posts: 1060
Joined: Oct 23, 2016 15:28
Location: Roma, Italia

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

Postby jj2007 » Sep 10, 2018 2:13

In principle a good idea. Maybe two (or more?) uses should be discussed:
1. more speed by using more than one core
2. prevent hanging of a Gui application by moving "blocking" stuff into a thread
Posts: 1317
Joined: Feb 26, 2007 5:32

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

Postby caseih » Sep 10, 2018 4:19

In dealing with multithreaded programming and synchronization issues, it's not only helpful to know about mutexes, but there are also other very useful primitives such as semaphores (counting semaphores), and queues (which use semaphores). There are numerous classic principles and problems that illustrate problem solving with threads including things like the producer/consumer model, the dining philosophers problem, etc. All worth studying.

Any tutorial about multithreading needs a big disclaimer, though. There's an old saying that applies very well to multithreading: If you have a problem and think, oh I can solve this with threads, now you have two (or more) problems!

Threading is very fraught and prone to synchronization problems, race conditions, heisenbugs, deadlock, and starvation. Programmers enter at their own peril!

Threads can be a neat solution to a pressing problem, but the pitfalls need to be clearly stated. There are some best practices, such as have been mentioned, but they can't prevent all issues. Often, asynchronous I/O (Windows, Linux, Mac all support this) solves the problem without threads at all, particularly in a GUI loop.

Return to “Documentation”

Who is online

Users browsing this forum: No registered users and 1 guest