Re: Gforth pthreads support

[Bernd Paysan]

Am Sonntag, 25. Juli 2021, 07:26:29 CEST schrieb David Kuehling:
> Hi,
> 
> I'm just starting to write multi-threaded Gforth programs for the first
> time and stumbled over what looks like an inconsistency in the API [1]:
> 
> While I can start new threads using newtask and pass/activate, there is
> no obvious way to synchronize the main thread against concurrently
> running threads.  I.e. if I naively run one ore more workers using
> 
>   : spawn-workunit
> 
>      stacksize4 newtask4 pass
>      \ work to do
>      ;
> 
> Than the main program will just continue until BYE, which will not wait
> on any of the active threads (and maybe cause some crashing when Gforth
> attempts to exit while threads are still accessing various data).

I've decided to leave that up to the user, because the system doesn't even 
keep track of the spawned threads (cilk.fs keeps track of all idle threads, 
and counts the active ones).

The remaining problem is that the threads haven't actually finished when they 
decrement the counter, and pthread_join() doesn't work, because they are 
detached, and can't be re-attached.  So that's why there is a 1 ms sleep in 
cilk.fs.

> The API seems to be built to allow message passing back to the main
> thread using <event ... event>.  However, there is no documented way to
> reference the main thread when doing so.  It seems that the otherwise
> undocumented word UP@ can be used to reference the main thread, so by
> trial&error (and looking at implementation and some example code) I
> found this code to be doing what I need:
> 
>   VARIABLE spawned  0 spawned !
>   event:  unspawn  -1 spawned +! ;
>   up@ CONSTANT main-task
> 
>   : spawn-workunit
> 
>      1 spawned +!
>      stacksize4 newtask4 pass
>      \ work to do
>      <event unspawn main-task event>
>      ;
> 
>   : join
> 
>      LOOP
>      \ event loop until all threads done
>      BEGIN spawned @ WHILE stop REPEAT ;
> 
> Also the documentation is not exactly clear on what happens when a
> function that started a thread via activate / pass exits.  Looking at
> pthread.fs I think the thread actually exits cleanly, but as Gforth
> mixes pthread semantics with some non-pthreads message passing API,
> reading the manual I feared it may enter the event loop on EXIT.

It should exit cleanly.

> Note also, that for some reason, the glosgen comments for <event &
> friends are missing from the manual.

No problem here.  Also the OpenSuSE Build service works fine.  The Debian 
build failed.  I'll have a look.

> Other than that, I'm quite happy with the <event API.  Having dealt with
> a deadlocks in huge C++ applications, I really appreciate being able to
> fully handle synchronization using message-passing only.
> 
> cheers,
> 
> David
> 
> PS: looking at silk.fs, I may have been reinventing the wheel here.
> 
> [1] https://gforth.org/manual/Pthreads.html


-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o id: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
https://net2o.de/

signature.asc
Description: This is a digitally signed message part.