Recent

Author Topic: WinThreadManager not consistently used  (Read 615 times)

Bi0T1N

  • New Member
  • *
  • Posts: 36
WinThreadManager not consistently used
« on: April 07, 2020, 10:25:13 pm »
Hello,
I've had a look into the ThreadManager mechanism because I thought about implementing thread naming as TThread.NameThreadForDebugging doesn't do anything yet.

However, I have some questions now:
1. The WinThreadManager is initialized through the TLS callback (regarding comments in system.pp) or directly in system.pp by following statement
Code: Pascal  [Select][+][-]
  1. if not Assigned(CurrentTM.BeginThread) then
while the default used startup TThreadManager is in inc/thread.inc (as far as I've understood) and always sets
Code: Pascal  [Select][+][-]
  1. BeginThread            : @NoBeginThread;
so how can it be nil?

2. Why is
Code: Pascal  [Select][+][-]
  1. ThreadSetPriority      :=@SysThreadSetPriority;
defined and then not used in win/tthread.inc. It uses the WinAPI function name
Code: Pascal  [Select][+][-]
  1. procedure TThread.SetPriority(Value: TThreadPriority);
  2. begin
  3.   SetThreadPriority(FHandle, Priorities[Value]);
  4. end;
directly instead of the function assigned to the WinThreadManager (ThreadSetPriority) which points to SysThreadSetPriority. This is an inconsistency compared to the other platforms (SetPriority is just one example I've picked).
Is there any special reason for this inconsistency?

Fred vS

  • Hero Member
  • *****
  • Posts: 1779
    • StrumPract is the musicians best friend
Re: WinThreadManager not consistently used
« Reply #1 on: April 07, 2020, 10:51:19 pm »
Hello.

I fear that thread.priority is not yet implemented.

In cthreads.pp

Code: Pascal  [Select][+][-]
  1. function  CThreadSetPriority (threadHandle : TThreadID; Prio: longint): boolean; {-15..+15, 0=normal}
  2.     begin
  3.       {$Warning ThreadSetPriority needs to be implemented}
  4.       result:=false;
  5.     end;
  6.  
  7.  
  8.   function  CThreadGetPriority (threadHandle : TThreadID): Integer;
  9.     begin
  10.       {$Warning ThreadGetPriority needs to be implemented}
  11.       result:=0;
  12.     end;

Changing thread priority needs root access for Linux and FreeBSD.

It seems that for Windows 10 now you need administrator access to change it:
https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreadpriority#remarks

Fre;D
« Last Edit: April 08, 2020, 12:06:57 am by Fred vS »
I use Lazarus 2.0.6 32/64 and FPC 3.2.0 32/64 on Debian 10.2 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64 and Mac OS X Snow Leopard 32.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt, Carbon.

https://github.com/fredvs

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8583
  • FPC developer.
Re: WinThreadManager not consistently used
« Reply #2 on: April 07, 2020, 11:13:42 pm »
Priority afaik was windows only. It could be that later a threadmgr one was added, but windows was not changed.

The other one seems to indeed have the assigned because one route might be earlier than the other.

But that initialization of inc/thread.inc is under $ifndef DISABLE_NO_THREAD_MANAGER

and win32/system.pp defines DISABLE_NO_THREAD_MANAGER

So that means that the variable is uninitialized, and since windows zeroes memory on startup unassigned.


PascalDragon

  • Hero Member
  • *****
  • Posts: 1939
  • Compiler Developer
Re: WinThreadManager not consistently used
« Reply #3 on: April 08, 2020, 10:31:11 am »
I fear that thread.priority is not yet implemented.

It's implemented on Windows (see the excerpt mentioned by Bi0T1N).

hanging thread priority needs root access for Linux and FreeBSD.

Only when you want to have realtime priority.

It seems that for Windows 10 now you need administrator access to change it:
https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreadpriority#remarks

I can't see that mentioned anywhere. Please quote it where you think that is the case.

Bi0T1N

  • New Member
  • *
  • Posts: 36
Re: WinThreadManager not consistently used
« Reply #4 on: April 08, 2020, 11:30:12 am »
Priority afaik was windows only. It could be that later a threadmgr one was added, but windows was not changed.
Seems like that priority is an exception because of the TThreadPriority type in
Code: Pascal  [Select][+][-]
  1. procedure TThread.SetPriority(Value: TThreadPriority);
while the default method in inc/thread.inc uses
Code: Pascal  [Select][+][-]
  1. function  ThreadSetPriority (threadHandle : TThreadID; Prio: longint): boolean;
  2. begin
  3.   Result:=CurrentTM.ThreadSetPriority(ThreadHandle,Prio);
  4. end;
However, it could call ThreadSetPriority in SetPriority for consistency (like unix/cthreads does).

But that initialization of inc/thread.inc is under $ifndef DISABLE_NO_THREAD_MANAGER

and win32/system.pp defines DISABLE_NO_THREAD_MANAGER
Oh yes, you're absolutely right. I've overlooked that define.

hanging thread priority needs root access for Linux and FreeBSD.

Only when you want to have realtime priority.

You can instead set the niceness with the setpriority function but
Quote
According to POSIX, the nice value is a per-process setting.
However, under the current Linux/NPTL implementation of POSIX
threads, the nice value is a per-thread attribute: different threads
in the same process can have different nice values.
Portable applications should avoid relying on the Linux behavior, which may be
made standards conformant in the future.
http://man7.org/linux/man-pages/man2/setpriority.2.html
But as it's like this for many years now I don't think that they will ever change that. Seems more like it's intended.

 

TinyPortal © 2005-2018