I just want to make thread since I don’t want my game to stop because of overhead of texture loading from SSD/HDD.
but different processor cause false sharing.
I don’t need multi processor to work for speed.
Threads will run on the next available core, which may be the same that started it.
If you want to avoid using multiple cores just fork a new process.
I doubt it. How threads are scheduled is up to the OS. A thread might start running on one core but later run on another core. The switch might happen at any time.
different processor cause false sharing.
Do you actually have a performance problem caused by false sharing or are you just worried prematurely? False sharing is mainly a problem when a thread frequently accesses data that is stored very close to some other data that is being frequently modified by another thread.
I don’t want my game to stop because of overhead of texture loading
That is fair, but be careful. Not all SDL functions are safe to call from other threads. I guess that calling IMG_Load is probably safe but SDL_CreateTextureFromSurface is not. Note that IMG_LoadTexture calls SDL_CreateTextureFromSurface internally so that is also not safe to call from other threads.
Processes can run on different cores so I don’t see how this would help. Communicating between the processes would also be more difficult and possibly inefficient. Is it even possible to share a SDL_Texture between processes?
I just worried prematurely.
since I thought old ram has very slow access speed.
so, it won’t cause trouble with short data size?
ex: sometime need to read 400Byte per 16~17ms that is edited by other thread.
I only call IMG_Load which won’t use renderer then, create surface and store it.
only 1 thread call SDL_CreateTextureFromSurface.
but I can’t make out IMG_Load is thread-safe or no.
Is RWops is thread-safe right? then IMG_Load should be, but I don’t know exactly. perhaps yes.
sry, I don’t want to use non SDL API.
It depends on what you compare it to. It’s slower than reading from the CPU cache or a register but much faster than SSD/HDD.
it won’t cause trouble with short data size? ex: sometime need to read 400Byte per 16~17ms that is edited by other thread.
No. That doesn’t sound like it will be a problem at all. The cost of a “cache miss” (due to false sharing or otherwise) is not that huge. It only becomes a problem if it happens frequently enough.
If both threads read the same data then that’s not “false sharing”. It’s “true sharing” and for it to work correctly you need to use a synchronization mechanism such as mutexes or atomics.
I can’t make out IMG_Load is thread-safe or no.
SDL_LoadBMP can be called from any thread and I don’t see any reason why the same would not be true for IMG_Load.
Unfortunately, the docs for SDL_image seems to lack information about thread safety.
I searched around a bit and found some people saying they use it from other threads without problem. That of course doesn’t prove anything.
1 Like
I misunderstood that both true sharing and false sharing as just false sharing.
I understand.
Ok. seems mechanics this topic suggest works finely and for most situations.
thank you.
You might be overthinking the problem. SDL(3) has a async API for files which might fit your usecase because IIRC you can only create textures on the main thread. I’m positive on linux you can say which thread your thread is allowed to run on (but after it’s created). I’m not convinced you thought clearly thought about the problem because how would you be able to falsely share a file that isn’t loaded into memory 
I didn’t say it’s gonna be faster, OP stated he does not want to use multi-threading, the motivation is unclear to me.
Is it even possible to share a
SDL_Texturebetween processes?
I’m not sure, I know you can’t create one on other threads then the one where video module have been initialized (986).
FYI in SDL3 it explicitly says main thread. I’m not sure what OS would allow that to work reliability outside the main thread SDL3/SDL_CreateTexture - SDL Wiki
Surfaces can be created anywhere
1 Like
To clarify: GPU accelerated api - not good for threads (so long you’re not using vulkan externally). CPU api - good for threads. c: