Threading

ID:132382
 
Feb 17 2011, 6:52 pm
I tried putting together a small threading library a couple months ago before I realized the obvious, that byond can't really handle threading the way that C based languages do, yet.

So it'd be nice to see support for threading. Like I want to know what threads are active by their numbers and which have stopped.

some pseudo:

activeThreads=0

thread
  ISALIVE=FALSE //using byond convention, I assume
  functionPointer = null
  threadID = -1
  proc/CheckState()
  proc/SpawnNextThread()
  New()
       .=..()
       if(.)
          threadID = activeThreads + 1
          if(functionPointer != null)
             SpawnNextThread()


You get the point. I'm exhausted and sick, but I thought of how I screwed around with byond a couple months ago and forgot to post anything about this. So the idea is...add support for "threading" (interpret this however byond actually works). It would be nice to run things concurrently in a more efficient and transparent manner.
Feb 17 2011, 8:47 pm
I don't see how true concurrency can ever happen. If BYOND became multithreaded we'd have to add all sorts of crap like semaphores and mutexes, and users would have to deal with the fallout of threading. The spawn() statement basically allows a non-preemptive form of multitasking, but only one proc can ever be running at once if the integrity of the internal objects is ever to be trusted.

To give you an idea of some of the problems, picture two procs running on different threads but accessing the same obj. Say proc #1 deletes the obj. Proc #2 may be in the middle of a routine that deals with the obj's internals, and can't allow the obj to be truly deleted. If it is, you get an instant crash when proc #2 tries to access one of the structure's variables. Then we'd not only have to have the regular refcounts, but a special internal refcount that we strictly obeyed that would prevent the actual item from being deleted. So much would have to be changed internally that this would be a massive overhaul.

And that doesn't even begin to bring up other potential timing issues, the kinds that OS programmers rip out their hair over, which would be the problem of the end user.

Lummox JR
Feb 20 2011, 11:32 am
In response to Lummox JR
Ahhh I see. So you'd run into the problem of an object's resources being accessed by 2 different threads at the same time. I didn't even think about that. So it would be a great deal of added complexity. Darn semaphores and race conditions.

Thanks for the thorough response! (It really took me back to one of my early CS classes.)
Feb 21 2011, 9:07 am
In response to Lummox JR
Well Lummox I only somewhat agree, it should be at the programmers discretion to code it right & not create such problems as accessing the same thing over multiple threads & just explain that if they do so, BYOND will not be required to fix any problems that arise when using the threading system.

The threading system would be really great, I already use threading in C++ & such, C++ programs will even crash & such if you delete things that are being used, try & access variables, etc... from multiple threads....

I wouldn't expect BYOND to cover for stupidity any day, it's not like C++ or other languages will cover up for mistakes you made accessing or deleting or editing things form seperate threads.
Feb 21 2011, 9:57 am
In response to Superbike32
BYOND will have a lot of internal data structures that need to be synchronized, like the string pool. All of BYOND's code would need to be made thread-safe.
Feb 21 2011, 10:05 am
In response to Immibis
I am not saying it'd be easy just to do the basics of it without worrying about people screwing up even but even if it comes much later & only when major(longer) updates come along, this should not be ignored.