home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.forth      Forth programmers eat a lot of Bratwurst      117,927 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 117,510 of 117,927   
   Anton Ertl to Paul Rubin   
   Re: multitasking vs multiple interpreter   
   29 Jul 25 07:49:01   
   
   From: anton@mips.complang.tuwien.ac.at   
      
   Paul Rubin  writes:   
   >Question is how to multitask on a small embedded target.  One way is the   
   >traditional cooperative multitasker with a shared dictionary plus task   
   >variables.   
   >   
   >Another way is time slicing multiple interpreters, each with its own   
   >data dictionary (all variables are task variables).  There would be a   
   >shared read-only dictionary for code and constants, and a mailbox scheme   
   >for IPC.   
   >   
   >This question is more about shared vs non-shared than cooperative vs   
   >preemptive.  The latter would be Erlang-style preemptive, i.e. avoiding   
   >most locking hazards by using mailboxes instead of memory sharing.   
   >   
   >Does anyone do it this way?  Is the overhead substantial?   
      
   Gforth is not for small embedded systems, but anyway, the development   
   version does multi-tasking by mapping each task to a POSIX thread   
   (within one process), with the classical USER variable mechanism for   
   task-local variables, multiprocessing/preemption (coming from POSIX   
   threads), and an actor-like mechanism for communicating between tasks   
   and for synchronizing them (there are also other synchronizing   
   mechanisms).  The messages that the actor-like mechanism delivers to   
   the mailbox of a task are xts that the receiving task executes.  You   
   can read about that in https://net2o.de/gforth/Multitasker.html.   
      
   Concerning the idea of replicating all variables and buffers in each   
   task, that seemed too expensive in memory for Gforth, and I expect   
   that it is considered too expensive all the more for small embedded   
   targets.  For Gforth we want to be able to support a huge number of   
   tasks (although the current implementation with one pthread per task   
   is probably too expensive for that, too, but a future implementation   
   can fix that), for a small embedded system you may only want to have a   
   few tasks, but even then you don't want to waste memory on replicating   
   buffers that are only used in one task.  There is a reason why Forth   
   has both VARIABLE and USER.   
      
   - anton   
   --   
   M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html   
   comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html   
        New standard: https://forth-standard.org/   
   EuroForth 2025 CFP: http://www.euroforth.org/ef25/cfp.html   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca