PureBasic Forums - English

Can the pointer that's used internally to keep track of current element be specified "threaded" so each tread has its own copy and reading a list or map becomes threadsafe?

Btw would be nice to be able to specify data type of key too instead of forced string...

You can save the pointer for each thread by yourself. You can only have one item being specified as the selected item any given time, so if two threads access the same list simultaneously it won't work. Instead you can use either maps (if every thread accesses a different item) or manipulate the data from the saved pointer (which I don't know if it's that easy). Otherwise use locks or whatever to be sure only one thread accesses the list any given time, which slows the threads down. PS: I have a complex program running 26 threads on startup filling a map with lots of data. Each thread has its own structured map element with lots of of subitems, including other maps and lists. Works like a charm.

I hope I gave you the correct information, otherwise someone may correct me.

I know of some workarounds. Still won't fix multiple simultaneous foreach loops. Only works if the internal pointer would be per-thread. Curious that's not the case. Would make mutexes for readonly access unnecessary, and therefore a non-blocking execution.

What kind of workarounds do you know?

Low hanging fruit improvement, no?

And for what is a Mutex?

Lists can never be threadsave by itself, because elements can be deleted and added.
How do you compensate this in a different thread?
You are standing on an element which is just deleted by an other thread for example.

There is no thread protection on list/map in PB, so you need to do it yourself with mutexes. We could add such in threadmode, but it will probably impact the performances for all lists/maps so I don't know if it worths it.

infratec wrote: Mon Apr 11, 2022 7:31 am And for what is a Mutex?

Lists can never be threadsave by itself, because elements can be deleted and added.
How do you compensate this in a different thread?
You are standing on an element which is just deleted by an other thread for example.

I am talking about concurrent read access so you can do a read-foreach in multiple threads simultaneously. Which can be threadsafe by default (and is in many other languages afaik). When you want to modify it you ofcourse use a mutex to get exclusive access, which will also block read access elsewhere. Maybe I oversimplify things.. maybe reading the map can set a atomic counter for threaded readonly access until it is done after which mutexed modify action is allowed again.

Well, thanks for thinking it over.

Why not use MapSize() and a regular loop without ForEach..Next?
Concurrent reads would be safe as long as you used semaphore|mutex.

skywalk wrote: Mon Apr 11, 2022 6:43 pmWhy not use MapSize() and a regular loop without ForEach..Next?

How should this work?
It is not possible to use item index: It is only possible to use ForEach or While (with ResetMap and NextMapElement) to iterate through map elements.
Both methodes are not threadsafe.

Did I missed something?
I am always ready to learn new things.

Yes, the While, but you increment a self counter.
And use Semaphore|Mutex.
ForEach macro scares me.

ps. even if you, as the programmer, know for sure you will not modify the list once populated, you still cannot read from multiple threads simultaneously because the current element pointer is not "threaded" but shared, so every ForEach will mess with each other. Which is why I requested this in the first place. At least make the read pointer threaded (as in keyword Threaded in PB). Which is an easy first step to improve I think?

To edit an existing list over two threads, I also use two lists. One with the data and one with the pointers to the data.

mk-soft wrote: Tue Apr 12, 2022 11:38 am To edit an existing list over two threads, I also use two lists. One with the data and one with the pointers to the data.

That is one way.

You could also iterate through the list in one thread and pass the items to several threads to work on the items in parallel running threads.