[DONE] Threads & Memory

Just starting out? Need help? Post your questions and find answers here.
User avatar
tft
User
User
Posts: 84
Joined: Mon Dec 29, 2008 9:34 am

[DONE] Threads & Memory

Post by tft »

Hallo

I have a question about memory access from multiple threads. Is it just writing to a memory address that causes a problem, or reading? Or even both? I know how to use mutex. The question is of a more informal nature.

THX TFT

Google Translater

"Driving School Evergarden" on "Pure Basic to go" of YouTube (German)
Last edited by tft on Mon Aug 29, 2022 10:53 am, edited 1 time in total.
TFT seid 1989
Aktuelles Projekte : Driving School Evergarden
YouTube : Pure Basic to go
FaceBook : Temuçin SourceMagic Games
DISCORD : SourceMagic
W10 , i9 9900K ,32 GB Ram , GTX Titan , 3 Monitore FHD
ARDUINO Freak :-)
User avatar
Caronte3D
Addict
Addict
Posts: 1025
Joined: Fri Jan 22, 2016 5:33 pm
Location: Some Universe

Re: [HELP] Threads & Memory

Post by Caronte3D »

Both (reading & writing), so you must use mutex or some semaphore in both cases.
acreis
Enthusiast
Enthusiast
Posts: 182
Joined: Fri Jun 01, 2012 12:20 am

Re: [HELP] Threads & Memory

Post by acreis »

Good morning. I suppose one integer value can be read safely with no mutex. The reason is how could you store the mutex handle and use it in concurrent threads?
User avatar
spikey
Enthusiast
Enthusiast
Posts: 581
Joined: Wed Sep 22, 2010 1:17 pm
Location: United Kingdom

Re: [HELP] Threads & Memory

Post by spikey »

Neither is a problem in and of itself. It's the potential for both to be happening to an item of data at the same time that is the problem because the winner of the competition may be indeterminate and this can lead to data corruption or loss of program control.

Suppose we have a string A$ and there are two threads X and Y. Both want to modify A$. X is going to modify a selection in the middle and Y is going to append to the end. Neither of these actions is a problem on their own sequentially but in a thread problems can result.

1) X starts work. It has been provided with a pointer to A$. It modifies the string at the end of its code but a loop at the beginning takes a while to conclude.
2) Meanwhile Y starts up during X's loop.
3) Y lengthens the string, which causes the string storage in memory to be reallocated by the OS and the pointer in A$ changes.
4) X no longer has a valid location for A$ but is unaware of this. It writes its updated content back to the old location regardless when it gets to the end of its code. It doesn't raise an error because it thinks the job's been done properly.
5) Y finishes and writes back its modified string to the new location completely ignoring the changes that X was trying to make. It too can't detect an error condition though.
6) The content of A$ is now whatever Y wrote and X's changes have been lost but no part of the program will have signalled any kind of failure.

Furthermore simply adding a mutex to these threads won't solve the problem. Their basic design is flawed because of the points at which a pointer is created and modified.

This is just one example there are many others; simultaneous changes of a memory buffer or a linked list...
If it's control data not user data then program control could be lost leading to a process crash.
Last edited by spikey on Thu Aug 18, 2022 1:44 pm, edited 7 times in total.
User avatar
NicTheQuick
Addict
Addict
Posts: 1223
Joined: Sun Jun 22, 2003 7:43 pm
Location: Germany, Saarbrücken
Contact:

Re: [HELP] Threads & Memory

Post by NicTheQuick »

It depends on what you want to do. If you want to read just one atomic value which is not bigger than the register size of 64 bits, then it should be safe. But if you read multiple values or a whole memory block, you better use a mutex.
For example it would be a bad idea to first read the length of an array and then iterate over it. In the meantime an other thread could have changed the size of the array which not only could result in wrongly iterating over the end of the array but could also result in completely miss the elements of the array because it has to be moved to a completely different space in memory.

I hope that makes it clear.
The english grammar is freeware, you can use it freely - But it's not Open Source, i.e. you can not change it or publish it in altered way.
User avatar
tft
User
User
Posts: 84
Joined: Mon Dec 29, 2008 9:34 am

Re: [HELP] Threads & Memory

Post by tft »

The question is only about data that is not manipulated for the query. I use the mutex to allow data manipulation from only one thread. Just like with double buffering. However, I would like to allow several threads to read the same memory area.
TFT seid 1989
Aktuelles Projekte : Driving School Evergarden
YouTube : Pure Basic to go
FaceBook : Temuçin SourceMagic Games
DISCORD : SourceMagic
W10 , i9 9900K ,32 GB Ram , GTX Titan , 3 Monitore FHD
ARDUINO Freak :-)
User avatar
spikey
Enthusiast
Enthusiast
Posts: 581
Joined: Wed Sep 22, 2010 1:17 pm
Location: United Kingdom

Re: [HELP] Threads & Memory

Post by spikey »

It depends how often the data will be written and how consistent the reads must be. Reads will be consistent when no writes are taking place. You can't guarantee two reading threads will get the same read data whilst a writing thread is writing in the same section. It's a race condition.
User avatar
tft
User
User
Posts: 84
Joined: Mon Dec 29, 2008 9:34 am

Re: [HELP] Threads & Memory

Post by tft »

Why should the data change? If assured, by a write mutex. That definitely no data is written in the memory area at the time of reading. The operating system must surely have a protective mechanism. As long as no ASM commands are used. In addition, the data to be read are not read directly from memory. But preloaded in the internal cache. What I want to do becomes complex. Therefore, I would like to find out beforehand whether I can expect problems. My concern is that I don't get any crashes from reading processes.
TFT seid 1989
Aktuelles Projekte : Driving School Evergarden
YouTube : Pure Basic to go
FaceBook : Temuçin SourceMagic Games
DISCORD : SourceMagic
W10 , i9 9900K ,32 GB Ram , GTX Titan , 3 Monitore FHD
ARDUINO Freak :-)
User avatar
spikey
Enthusiast
Enthusiast
Posts: 581
Joined: Wed Sep 22, 2010 1:17 pm
Location: United Kingdom

Re: [HELP] Threads & Memory

Post by spikey »

tft wrote: Thu Aug 18, 2022 2:50 pm Why should the data change?
Timing. Timing becomes significant in threaded programs in a way that is completely precluded by non-threaded programs. How much data are you talking about at any one time? How long will your actions take? Will there be read/write point overlap potential at any stage? What happens if a read was started just before a write starts so that the reader got an ok on the mutex but the writer locks it immediately afterwards, but the reader won't get to the write point first because it was reading more than the writer will. Could a read still be in progress at the point the writer plans to write?

If reads and writes only ever take place at completely separate and non-overlapping points in the buffer then its ok, for example a ring buffer. However if there's any chance of overlap at any time then you can't guarantee complete atomic consistency to multiple readers overall. You might get it, you might not. If you can tolerate this then its also ok. If you can't, then its not.

The mutex doesn't actually protect anything in the sense of stopping something happening itself automatically, it's a managed flag. It just provides a mechanism whereby a well written program can stop something nasty happening but its the program that prevents the nastiness not the mutex. The point is though that the mutex itself won't suffer from indeterminacy; you can guarantee it won't be unlocked when it should be locked or locked when it should be unlocked.
juergenkulow
Enthusiast
Enthusiast
Posts: 544
Joined: Wed Sep 25, 2019 10:18 am

Re: [HELP] Threads & Memory

Post by juergenkulow »

Code: Select all

; Two threads access one memory area. 
#MAXMEM=256

Procedure incmem(*ptr.BYTE)
  Protected i=0
  Repeat
    *ptr\b=*ptr\b+1
    *ptr=*ptr+1
    i=i+1
    If i>=#MAXMEM
      *ptr=*ptr-#MAXMEM
      i=0
    EndIf 
  ForEver
EndProcedure

Procedure decmem(*ptr.BYTE)
  Protected i=0
  Repeat
    *ptr\b=*ptr\b-1
    *ptr=*ptr+1
    i=i+1
    If i>=#MAXMEM
      *ptr=*ptr-#MAXMEM
      i=0
    EndIf 
  ForEver
EndProcedure

*mem=AllocateMemory(#MAXMEM)
CreateThread(@incmem(),*mem)
CreateThread(@decmem(),*mem)
For i=1 To 20
  ShowMemoryViewer(*mem,#MAXMEM)
  Delay(500)
Next 
; 0000000001FD88A8  E3 E8 E8 E7 E8 E8 E8 E5 E7 E7 E9 E6 E8 E9 E9 E8  ãèèçèèèåççéæèééè
; 0000000001FD88B8  E7 E7 E7 E9 E6 E8 E9 E7 EA E7 E8 E8 E7 E8 E7 E8  çççéæèéçêçèèçèçè
; 0000000001FD88C8  E7 E5 E7 E9 E9 E8 E8 E8 E6 E7 E8 E7 E7 E9 E9 EA  çåçééèèèæçèççééê
; 0000000001FD88D8  E8 E9 EB E9 E9 E9 E7 E9 E9 E7 E8 E9 E8 E9 E9 E7  èéëéééçééçèéèééç
; 0000000001FD88E8  E7 E8 E8 E7 E7 E9 E8 E9 E8 E8 E9 EA E8 E9 E9 E9  çèèççéèéèèéêèééé
; 0000000001FD88F8  E7 E8 EB E8 E8 E7 E9 E9 E5 EA E7 E7 E8 E9 E9 E8  çèëèèçééåêççèééè
; 0000000001FD8908  E8 E8 E9 E9 E9 E8 E8 E6 E9 E9 EA E9 E7 E9 EA E8  èèéééèèæééêéçéêè
; 0000000001FD8918  E8 EB E9 E8 EA E4 E9 E9 E9 EA EA E7 EA EA EB E7  èëéèêäéééêêçêêëç
; 0000000001FD8928  E8 EA EB E9 E7 E9 E9 E9 E9 E9 EA E6 EA EA E9 E7  èêëéçéééééêæêêéç
; 0000000001FD8938  E7 EA E8 E7 E6 E8 EA EA EA E9 E6 E8 E9 EB E9 E8  çêèçæèêêêéæèéëéè
; 0000000001FD8948  E9 E6 E8 E7 E9 E9 E9 E9 E9 E9 E7 E9 EA E9 E9 E8  éæèçééééééçéêééè
; 0000000001FD8958  E7 E9 E7 E9 E7 E9 E8 E8 E9 E9 E6 EA E8 E8 E9 E8  çéçéçéèèééæêèèéè
; 0000000001FD8968  EB E7 EA E8 E9 E8 E7 E8 E6 E6 E6 E6 E7 E9 E7 E8  ëçêèéèçèææææçéçè
; 0000000001FD8978  E8 E8 E6 E6 E4 E8 E7 E8 EB E7 E7 E9 E7 E9 E6 E7  èèææäèçèëççéçéæç
; 0000000001FD8988  E6 E7 E8 E6 E8 E8 E5 EA E7 E6 E7 E8 E7 E9 E7 E7  æçèæèèåêçæçèçéçç
; 0000000001FD8998  E8 E6 E8 E6 E9 E7 E9 E9 E8 E6 E8 E9 E9 E7 E9 E8  èæèæéçééèæèééçéè
; Also look at the CPU usage.

; CompilerIf 0=#PB_Compiler_Thread 
;   CompilerError "please switch on thread save."
; CompilerEndIf
Please ask your questions, because switch on the cognition apparatus decides on the only known life in the universe.Wersten :DDüsseldorf NRW Germany Europe Earth Solar System Flake Bubble Orionarm
Milky Way Local_Group Virgo Supercluster Laniakea Universe
Marc56us
Addict
Addict
Posts: 1477
Joined: Sat Feb 08, 2014 3:26 pm

Re: [HELP] Threads & Memory

Post by Marc56us »

tft wrote: Thu Aug 18, 2022 2:50 pm ... The operating system must surely have a protective mechanism. ...
The operating system only prevents your program from writing to the memory space used by another program already running, but does not check anything about what your program does in the free space or occupied by your variables. So it does not protect against variable misuse between threads.
Post Reply