topic proposal: differences/changes when you move to multithread

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

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

Postby fxm » Mar 22, 2019 14:57

fxm wrote:
fxm wrote:..........


- I added in the post #1 of this article a very short introduction to multi-threading

I also recently added two posts (#8 and #9) to this article:
- post #8: Beware when using SCREENLOCK with multi-threading!
- post #9: Beware when using "video paging (double buffering or page flipping)" with multi-threading!
MrSwiss
Posts: 3216
Joined: Jun 02, 2013 9:27
Location: Switzerland

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

Postby MrSwiss » Mar 22, 2019 18:09

fxm wrote:

Code: Select all

Type thread_common_data
    Static As Any Ptr   MLock            ' declare the common MUTEX (to all threads!)
    As Any Ptr          TI               ' pointer to the specific Type instance for the thread
End Type

I don't get the reason, for the 'Static' specifier in the Type, as well, as it throws an error:
FBC 1.06.0 x64, WIN wrote:C:\DEV_TOOLS\FreeBASIC\1060_64\fbc -s console "FbTemp.bas"
FbTemp.o:fake:(.rdata$.refptr._ZN11COMMON_DATA6MLOCK$E[.refptr._ZN11COMMON_DATA6MLOCK$E]+0x0): undefined reference to `COMMON_DATA::MLOCK$'

Build error(s)

No 'Static', no ERROR ... (just: As Any Ptr).
fxm
Posts: 9123
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

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

Postby fxm » Mar 22, 2019 18:52

fxm wrote:

Code: Select all

Type thread_common_data
    Static As Any Ptr   MLock            ' declare the common MUTEX (to all threads!)
    As Any Ptr          TI               ' pointer to the specific Type instance for the thread
End Type
Dim As Any Ptr          thr_data.MLock   ' define the common MUTEX (to all threads!)  ********** Do not forget this line

See the STATIC (Member) documentation page.
MrSwiss
Posts: 3216
Joined: Jun 02, 2013 9:27
Location: Switzerland

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

Postby MrSwiss » Mar 22, 2019 18:59

You don't seem to understand:
there is absolutely NO reason, to declare the mutex 'Static' in the Type ...
(therefore, your additional line is sort of: redundant, anyway)
fxm
Posts: 9123
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

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

Postby fxm » Mar 22, 2019 19:00

Study the documentation page I quoted before criticizing!
MrSwiss
Posts: 3216
Joined: Jun 02, 2013 9:27
Location: Switzerland

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

Postby MrSwiss » Mar 22, 2019 19:10

You still don't make sense, because there is only a single instance of Type needed ...
fxm
Posts: 9123
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

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

Postby fxm » Mar 22, 2019 19:13

Well, for my part, I stop here our discussion.
Other users can take over here (if they wish).
MrSwiss
Posts: 3216
Joined: Jun 02, 2013 9:27
Location: Switzerland

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

Postby MrSwiss » Mar 22, 2019 19:44

<sarcasm on>
My Dad used to say: "Why do it simple, if it can also be done, in a much more complex way?".
<sarcasm off>

Meaning: a Static variable inside a Type = shared (see: Documentation)
(the Type itself, is therefore nothing but camouflage, for "shared")

This by extension means, we might as well use a: Dim Shared As Any Ptr mutex,
without the additional code complicating things ... Type with Ptr, to other Type.

At least, for simple examples, which don't need additional signalling (semaphores).
(I've clearly stated, a mutex only, unsychronized.)
dodicat
Posts: 5913
Joined: Jan 10, 2006 20:30
Location: Scotland

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

Postby dodicat » Mar 23, 2019 0:34

Why not use a namespace to hold variables and various functions.
They are then global but not seen until explicitly called.

Code: Select all

 
#include "fbthread.bi"

Namespace g
Dim As Long MySpeed=400
Dim As Integer mystop
Dim thread As Any Ptr
Function Regulate(Byval MyFps As Long,Byref fps As Long) As Long
    Static As Double timervalue,_lastsleeptime,t3,frames
    frames+=1
    If (Timer-t3)>=1 Then t3=Timer:fps=frames:frames=0
    Var sleeptime=_lastsleeptime+((1/myfps)-Timer+timervalue)*1000
    If sleeptime<1 Then sleeptime=1
    _lastsleeptime=sleeptime
    timervalue=Timer
    Return sleeptime
End Function
End Namespace

declare sub start

Sub DisplayProc(p As Any Ptr)
   
    Screenset 1,0
   
    Dim x As Long = 10
    Dim y As Long = 10
    Dim dx As Long = 1
    Dim dy As Long = 1
    Dim As Long fps,sleeptime
   
    Do
       
        sleeptime=g.regulate(g.MySpeed,fps)
        x += dx : y += dy
        If x<10 Or x>=630 Then dx = -dx
        If y<10 Or y>=470 Then dy = -dy
        Line(0,0)-(640,480),0,bf
        Line(0,0)-(640,480),15,b
        Circle(x,y),10,4,,,,f 'draw the ball
        Draw String(20,10),"Framerate I want = " &g.myspeed
        Draw String(20,30),"Framerate I get  = " &fps
        Flip
        Sleep sleeptime,1
       
    Loop While g.mystop=0
    ThreadDetach(g.thread) ''unsure about this bit
    g.thread=0
    End
End Sub

Sub start()
   
    Color 0,15
    Do
       
        Screenset 1,0
        Color  4
        Cls
       
        Locate 34
       
        Input "Enter a new framerate or zero to end ",g.MySpeed
       
        If g.myspeed<=0 Then g.mystop=1
       
    Loop
   
End Sub


Screen 19,,2

g.thread = Threadcreate(@displayproc) 'start running the sub

start

 
MrSwiss
Posts: 3216
Joined: Jun 02, 2013 9:27
Location: Switzerland

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

Postby MrSwiss » Mar 23, 2019 2:12

dodicat wrote:Why not use a namespace to hold variables and various functions.

I like the idea of a namespace, keeps things nicely separated.

I've slightly modified your code (removing the include) and, moving threading
into start() a Function now, to return: Error/OK state.

Code: Select all


Namespace g

    Dim As Long     MySpeed=400
    Dim As Integer  mystop
    Dim As Any Ptr  thread
   
    Function Regulate(Byval MyFps As Long,Byref fps As Long) As Long
        Static As Double timervalue,_lastsleeptime,t3,frames
        frames+=1
        If (Timer-t3)>=1 Then t3=Timer:fps=frames:frames=0
        Var sleeptime=_lastsleeptime+((1/myfps)-Timer+timervalue)*1000
        If sleeptime<1 Then sleeptime=1
        _lastsleeptime=sleeptime
        timervalue=Timer
        Return sleeptime
    End Function

End Namespace


Sub DisplayProc(p As Any Ptr)
   
    Screenset 1,0
   
    Dim x As Long = 10
    Dim y As Long = 10
    Dim dx As Long = 1
    Dim dy As Long = 1
    Dim As Long fps,sleeptime
   
    Do
        sleeptime=g.regulate(g.MySpeed,fps)
        x += dx : y += dy
        If x<10 Or x>=630 Then dx = -dx
        If y<10 Or y>=470 Then dy = -dy
        Line(0,0)-(640,480),0,bf
        Line(0,0)-(640,480),15,b
        Circle(x,y),10,4,,,,f 'draw the ball
        Draw String(20,10),"Framerate I want = " &g.myspeed
        Draw String(20,30),"Framerate I get  = " &fps
        Flip
        Sleep sleeptime,1
    Loop Until g.mystop ' <> 0

End Sub

Function start() As ULong

    g.thread = ThreadCreate(@DisplayProc)
    If g.thread = 0 Then Return 1   ' error
   
    Color 0,15

    Do
        Screenset 1,0
        Color  4
        Cls
        Locate 34
        Input "Enter a new framerate or zero to end ",g.MySpeed
        If g.myspeed<=0 Then g.mystop=1 : Exit Do
    Loop
    ' terminate thread signal dispatched (above)
    ThreadWait(g.thread)

    Return 0    ' all OK
End Function

' ===== MAIN =====
Screen 19,,2

Dim As ULong res = start()

End res ' return errorlevel (for .cmd use)
' ===== End-MAIN =====  ' ----- EOF -----
Not certain if it is a good idea, to do thread cleanup in it's own procedure.
Procedure exit's, before the thread is able to terminate ...
fxm
Posts: 9123
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

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

Postby fxm » Mar 23, 2019 6:34

@dodicat,
Why not also put the thread procedure (DisplayProc) inside the namespace?
Tourist Trap
Posts: 2762
Joined: Jun 02, 2015 16:24

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

Postby Tourist Trap » Mar 23, 2019 13:45

fxm wrote:
fxm wrote:
fxm wrote:..........


- I added in the post #1 of this article a very short introduction to multi-threading

I also recently added two posts (#8 and #9) to this article:
- post #8: Beware when using SCREENLOCK with multi-threading!
- post #9: Beware when using "video paging (double buffering or page flipping)" with multi-threading!

Thanks for those well redacted tips.
I jump here quickly. I wanted to ask if there are informations about how not interrupting a text input when doing multithreading with the text input methods of freebasic (INPUT essentially, maybe also INKEY and so on). Or, shouldn't we use the API of the OS that already do the job of multitasking etc... rather than FB here? Or even a librabry that does multithreading like openMP (if'm not mistaking on that point, maybe it's for parallel processing -> https://en.wikipedia.org/wiki/OpenMP)?
I dont know, just wondering. Thanks.
fxm
Posts: 9123
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

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

Postby fxm » Mar 23, 2019 15:34

Tourist Trap wrote:I wanted to ask if there are informations about how not interrupting a text input when doing multithreading with the text input methods of freebasic (INPUT essentially, maybe also INKEY and so on). Or, shouldn't we use the API of the OS that already do the job of multitasking etc... rather than FB here? Or even a librabry that does multithreading like openMP (if'm not mistaking on that point, maybe it's for parallel processing -> https://en.wikipedia.org/wiki/OpenMP)?
I dont know, just wondering. Thanks.

Maybe start by reading my post #7: User input-line function, but fully thread safe!
Tourist Trap
Posts: 2762
Joined: Jun 02, 2015 16:24

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

Postby Tourist Trap » Mar 23, 2019 15:49

fxm wrote:Maybe start by reading my post #7: User input-line function, but fully thread safe!

Thanks!
fxm
Posts: 9123
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

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

Postby fxm » Mar 24, 2019 7:39

fxm wrote:
fxm wrote:
fxm wrote:..........


- I added in the post #1 of this article a very short introduction to multi-threading

I also recently added two posts (#8 and #9) to this article:
- post #8: Beware when using SCREENLOCK with multi-threading!
- post #9: Beware when using "video paging (double buffering or page flipping)" with multi-threading!

I added and have just updated the post #10: When using the FB runtime library for multi-threaded applications, gfxlib2 is thread-safe :-)

Return to “Documentation”

Who is online

Users browsing this forum: No registered users and 2 guests