Hi guys.

I have a curiosity, regarding [1] - I had encountered some "undefined reference" errors when trying to link the druntime (compiled for an embedded architecture) without some implementation of the POSIX thread calls (and other stuff too).

My curiosity is what would change if I removed from the druntime everything that has to do with mutexes or threads. Would it be possible for the druntime to run and work properly on a microcontroller - where those concepts are not necessary? Could I just remove everything about synchronisation from the druntime, and classes or Garbage Collector to still work properly?

[1]: https://forum.dlang.org/post/erwfgtigvcciohllvaos@forum.dlang.org

On Tuesday, 20 October 2020 at 16:58:12 UTC, Severin Teona wrote:
> Hi guys.
>
> I have a curiosity, regarding [1] - I had encountered some "undefined reference" errors when trying to link the druntime (compiled for an embedded architecture) without some implementation of the POSIX thread calls (and other stuff too).
>
> My curiosity is what would change if I removed from the druntime everything that has to do with mutexes or threads. Would it be possible for the druntime to run and work properly on a microcontroller - where those concepts are not necessary? Could I just remove everything about synchronisation from the druntime, and classes or Garbage Collector to still work properly?
>
> [1]: https://forum.dlang.org/post/erwfgtigvcciohllvaos@forum.dlang.org

An alternative would be to link to a custom library that implements the pthreads ABI, but stubs everything out in a way that makes sense on a single-threaded microcontroller.

I wanted to do that once for another project.  I never got it to work for unrelated reasons, so I can't say how well the D runtime handles it, sorry.  It's probably an easier approach than maintaining your own fork of the runtime, though.

On Tuesday, 20 October 2020 at 16:58:12 UTC, Severin Teona wrote:
> Hi guys.
>
> I have a curiosity, regarding [1] - I had encountered some "undefined reference" errors when trying to link the druntime (compiled for an embedded architecture) without some implementation of the POSIX thread calls (and other stuff too).
>
> My curiosity is what would change if I removed from the druntime everything that has to do with mutexes or threads. Would it be possible for the druntime to run and work properly on a microcontroller - where those concepts are not necessary? Could I just remove everything about synchronisation from the druntime, and classes or Garbage Collector to still work properly?
>
> [1]: https://forum.dlang.org/post/erwfgtigvcciohllvaos@forum.dlang.org

Yes, you can stub the thread and mutex interfaces. You will of course not be able use that or any part of the library that uses threads  but you will be able to get to the main entry point and run a single threaded D program.

This is something we would want with the druntime API change, a stub that people can use when they don't need the functionality or as a starting point for implementing your own version.

On Tuesday, 20 October 2020 at 16:58:12 UTC, Severin Teona wrote:
> Hi guys.
>
> I have a curiosity, regarding [1] - I had encountered some "undefined reference" errors when trying to link the druntime (compiled for an embedded architecture) without some implementation of the POSIX thread calls (and other stuff too).

First, keep in mind that druntime and Phobos depends heavily on the C standard library, the Posix APIs, Windows APIs and other platform specific APIs. There's no list of what features or APIs need to be supported by a platform. There's no general concept of optional platform features, i.e. druntime will not automatically adopt if your platform doesn't support a specific feature (like threads). For example, on iOS (and related platforms) `std.process` is not supported (because you're not allowed to call `fork`). This is just hardcoded: if the platform is iOS, don't provide `std.process`.

What I'm saying, if you modify druntime to remove threads and locks, and resolve your undefined references, you might end up with new undefined references for other symbols.

> My curiosity is what would change if I removed from the druntime everything that has to do with mutexes or threads. Would it be possible for the druntime to run and work properly on a microcontroller - where those concepts are not necessary? Could I just remove everything about synchronisation from the druntime, and classes or Garbage Collector to still work properly?

The garbage collector will probably work (if you remove the interaction with threads from it). Classes are a bit more complicated, they have a hidden monitor field [1]. There's also the concept of synchronized classes [2]. There's also the `synchronized` statement [3]. All these depend on mutex/monitors/locks in some form (I don't know exactly how the implementation works). Hopefully it should be fine as long as your code doesn't use the `synchronized` statement or synchronized classes. But all classes do come with a hidden monitor field.

[1] https://dlang.org/spec/abi.html#classes
[2] https://dlang.org/spec/class.html#synchronized-classes
[3] https://dlang.org/spec/statement.html#synchronized-statement

--
/Jacob Carlborg

On Tuesday, 20 October 2020 at 16:58:12 UTC, Severin Teona wrote:

> My curiosity is what would change if I removed from the druntime everything that has to do with mutexes or threads.

Nothing if you don't plan to use multithreading.

I temporary disabled threading and appropriate unittests from my fork of druntime without any problem.

> Would it be possible for the druntime to run and work properly on a microcontroller - where those concepts are not necessary?

Sure

> Could I just remove everything about synchronisation from the druntime, and classes or Garbage Collector to still work properly?

Yes

On Wednesday, 21 October 2020 at 16:04:20 UTC, Denis Feklushkin wrote:
> On Tuesday, 20 October 2020 at 16:58:12 UTC, Severin Teona wrote:
>
>> My curiosity is what would change if I removed from the druntime everything that has to do with mutexes

As I remember, your plan is to use some type of RTOS. I am pretty sure what any RTOS provides, at least, mutexes.