It might be, but the non-threaded global long is behaving in such a way, that I’m left with the impression, that the main process (_main) has its “master copy” global variables, and then when a new thread is started, a copy of those globals is made which is part of the started thread process, which could explain the slowness seen when starting a thread, compared to a procedure hop.
Its at this point the globals can get out of synch.
Likewise if this started thread updates a global, its not reflected in the (_main) process globals straight away hence the need for some sort of syncher.
Behind the scenes, I think MS are starting a thread as a new process, as seen in task manager and other api’s, and copy the global variables to the started thread to mirror, so there is a newly created instance of global variables per new thread.
I think the reason for this is simply to make life easier for them (MS) when a started thread, runs on a different cpu or cpu core. Behind the scenes, MS then synch’s the unthreaded global variables at its leisure, but we can accelerate matters by using synchers like critical sections, mutexes and sempahores.
You can see this sort of behaviour on really slow machines like my DWP paid for £180 Lenovo laptop, you wont see it on a blazing fast 5.1Ghz desktop.
I’d love to, but I’m trying to reduce the overhead that comes with procedure hops, I know its only a few lines of assembler but I need to make this program as lightweight as possible.
It is, but I’ve managed to get a RegisterWindowMessageA and a SendMessageA subclass working across threads from thread 2, so I’ve been able to eliminate all the critical sections in the started thread (thread 3) that sets the global variable back to zero at the end of the procedure, which means I can now change the Glo:Thread to a Loc:Thread.
When its encountered, the SendMessageA jumps right back to the main frame subclass (thread 2) and processes the event/user message before returning back to the started thread (thread 3). I dont think I’m going to get it any quicker or using less code than that. But I’ve also had to remove the FrameExtension template, and roll my own Systray icon handling code as well, as the notify in it was causing problems by its nature of being LIFO and not FIFO.
(_main = thread 1)
(main = thread 2)
(RecordActivity = thread 3).
I think we are missing a trick by not having a RegisterWindowA/SendMessageA in the language imo.