Multithreading and Working around the GC
BlitzMax Forums/BlitzMax Programming/Multithreading and Working around the GC
| ||
| I have read that the BlitMax GC is not threadsafe and attempts to do multithreading in BlitzMax unreliable, resulting in crashes. What actually causes these crashes though? Is it just a case of reference counting going awry due do non-syncronisation. Aside from accesing an object which has been destroyed prematurely (which I'm guessing is happening) what else might cause crashes? As the threading I whish to do will only occur for finite time and periodically and there would be no significant memory allocation during this time. Could I simply just disable automatic garbage collection in this period to get round any issues? Are there any other workarounds/ carefull programming tips which would allow me to access blitz objects from multiple threads with garbage collection enabled? |
| ||
| As the threading I whish to do will only occur for finite time and periodically (Ok when you say Finite I assume you mean small as apposed to not InFinite) If so just use a timer Hook, as long as you have a pollEvent in your message/Main loop, and the other task wasnt long, then it would look like multithreading http://www.blitzmax.com/codearcs/codearcs.php?code=1721 or http://www.blitzmax.com/Community/posts.php?topic=69149#773096 |
| ||
| Yes, bad choice of terminoligy. Tasks will typically take up to a minute (perhaps longer). By finite I meant; not a looped task that lasts the duration of the program's lifecycle, but a series of one-off tasks. What I'm trying to do is achievable without threads but at the cost of performance, file IO for example. |
| ||
| You can also spawn another process to do these things and communicate with it through sockets, for example. That's not as sexy as using multithreading, but it won't have to worry about the garbage collector issues. |
| ||
| What actually causes these crashes though? Concurrent actions. What happens is that the so-called "critical section" of an object/algorithm is accessed by more than one thread which - in the best case scenario - results in an undefined result, often leading to random and arbitrary crashes. |
| ||
| So that's where you need to make some kind of lock thing, right, so that the code has to finish the critical part before another thread can? |
| ||
| right, and thats the point that you would need to add to the GC to prevent it from accessing objects you are working on. |
| ||
| Doesn't the GC only access private fields though? So it wouldn't be a case of the GC mangling objects you are working on as that memory space isn't going to get touched. Rather, is it GCCollect running concurrently in multiple threads that causes crashes or screwing up an objects reference count, perhaps deallocating them prematurely? In any case I should be fine disabling automatic Garbage Collection while a thread is running, yes? |
| ||
| @Winni Communicating through blocking Streams would probably have more of a performance hit than trying to do manual time-slicing. |
   |