Recent

Author Topic: Posix Threading Pre_Empt Naming  (Read 372 times)

timjones

  • New Member
  • *
  • Posts: 14
Posix Threading Pre_Empt Naming
« on: June 19, 2019, 02:47:16 am »
I have done a fair amount of work implementing realtime threading in lazarus (PreEmpt/Linux), and with a fair amount of testing I feel pretty confident that with the right components/tools, FPC/Lazarus would make an outstanding OSS RT industrial design platform.   The code I wrote was intended as proof of concept (ie. A hack job).   My next task is to redo everything and structure it correctly this time.   However, I am struggling in how I should introduce the Posix PreEmpt threading to FPC RTL.   While the synchronization code in TThread is somewhat useful, the Priority aspects were clearly written windows specific.  Also, even though TThreads were implemented on other platforms, the implementation is certainly not ideal from a Posix Threads standpoint. 

For compatibility concerns, should I just leave TThread alone and create a TPThread class and start from a clean slate, or do you think I should keep everything derived from TThread?

Thaddy

  • Hero Member
  • *****
  • Posts: 8927
Re: Posix Threading Pre_Empt Naming
« Reply #1 on: June 19, 2019, 09:29:56 am »
If you feel confident you are an experienced programmer I would always leave TThread alone: It is a convenience wrapper not geared towards performance in the sense that it enables less experienced programmers to still use threads in a more or less safe and easy manner. Mind you: it doesn't make thread programming easy, but easier...
Most people that want to use threading should learn to patch their jeans first: use a needle.

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 635
Re: Posix Threading Pre_Empt Naming
« Reply #2 on: June 19, 2019, 09:44:39 am »
PThread and windows threads are not compatible. Then again, most of the problems are in the locking and synchronizing, which you should use as little as possible anyway.

One of my former co-workers, a self-proclaimed Concurrent Processing Master, "solved" this by simply adding "lock" at the start of each function, and "unlock" at the end. Needless to say, that was very error-prone and much slower than simply doing everything sequentially.

So, try to remove everything that isn't strictly needed, and come up with a free-running model that doesn't need locking.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 7446
Re: Posix Threading Pre_Empt Naming
« Reply #3 on: June 19, 2019, 11:10:43 am »
I'd try to layer it over tthread first.  It and its interface is  is very widely used.

You don't want to make this for the few posix threads insiders only.

And document why you do things, and what is the problem with tthread's implementation.  The current tthread implementation was a massive improvement on the 1.0.x clone based threading (which I never got to even work on something non trivial)

« Last Edit: June 19, 2019, 11:12:24 am by marcov »

timjones

  • New Member
  • *
  • Posts: 14
Re: Posix Threading Pre_Empt Naming
« Reply #4 on: June 19, 2019, 03:00:27 pm »
I'd try to layer it over tthread first.  It and its interface is  is very widely used.

You don't want to make this for the few posix threads insiders only.

OK.  I will focus on layering the changes onto TThread then.