Hi All,

Can I use Sleep() in a thread to give up cpu time to other threads running at the same time, so as to adjust the relative "niceness" of a group of workers working on the same subject (in which each thread take part of the whole task).

Thanks!

Xiangrong

I presume most of the systems would make the sleeping thread to yield the execution time for other threads.
The questionable behavior might occur in case of sleep(0); (should it yield the remaining time or just return immediately - up to the OS). And multi-cpu might also do something different.

thanks,
Dmitry

2015-02-25 22:47 GMT+08:00 Dmitry Boyarintsev :

purpose of using threads is to take full advantages of all CPU cores.

As far as I know, setting thread priority does not always work, it may require root privilege for example. I would like to use Sleep() to control relative time share of all threads in the pool. For example, I run 3 threads on a dual-core system, with thread 1 and 2 share core-1, and thread 3 taking all computing power of core-2...

Now the problem is, can I use Sleep to control thread 1 to run at 50% of the speed of thread 2 (which is not throttled), providing that all threads are doing same kind of task, so that they are comparable?

Xiangrong​

not sure if this helps, but:
for example, if you want thread T to run using approx. 70% of max. available capacity, try this:

repeat
  T.Resume;
  Sleep(70);
  T.Resume;
  Sleep(30);
until ...

so T runs for 70 ms, then sleeps for 30 ms, etc

25.02.2015, 18:06, "Xiangrong Fang" :

I mean T.Suspend, so u resume it then suspend it

25.02.2015, 18:16, "" :

Use ThreadSwitch to yield CPU. Having said that, it may be better to look into platform specific thread scheduling rather than trying to do it yourself. For instance, with pthreads, you can do this:

procedure TYourThread.SetPriority;
{$ifdef unix}
var
	sp: sched_param;
begin
	sp.sched_priority := 10;
	{ SCHED_FIFO = 1 }
	pthread_setschedparam(ThreadID, 1, @sp);
end;
{$else}
begin
	// TODO
end;
{$endif}

Henry

Xiangrong Fang wrote

Can I use Sleep() in a thread to give up cpu time to other threads running at the same time

AFAIK:

Sleep(n) makes the thread give up CPU for _at_least_ n milliseconds

Sleep(0) makes it give up it's current time slice and is due to be re-scheduled rather soon.

sleep will not necessary give time to other threads. it also might give the time to other programs running on the system.

In an SMP OS multiple threads run at the same time, anyway. Sleep might make a thread run that before was waiting for a CPU.

-Michael

I mean T.Suspend, so u resume it then suspend it

TThread.Suspend and TThread.Resume are deprecated (since 2.4.4), don't use them.

Henry

2015-02-25 23:16 GMT+08:00 :

​This seems not what I want. I would like to schedule it from within the thread. My demo program is here:

https://github.com/xrfang/fpcollection/blob/master/src/demos/asyncdo/demo.lpr

TAsyncDo is the class I wrote to have a procedure run in parallel.

I want to control priority of the thread from within the worker, not from the main thread. ​

synchronising tools do not do what you want?

________________________________
De: em nome de Xiangrong Fang
Enviado: quarta-feira, 25 de fevereiro de 2015 12:33 Para: FPC-Pascal users discussions
Assunto: Re: [fpc-pascal] Use sleep in thread

2015-02-25 23:16 GMT+08:00 :
not sure if this helps, but:
for example, if you want thread T to run using approx. 70% of max. available capacity, try this:

repeat
  T.Resume;
  Sleep(70);
  T.Resume;
  Sleep(30);
until ...

?This seems not what I want. I would like to schedule it from within the thread. My demo program is here:

https://github.com/xrfang/fpcollection/blob/master/src/demos/asyncdo/demo.lpr

TAsyncDo is the class I wrote to have a procedure run in parallel.

I want to control priority of the thread from within the worker, not from the main thread. ?

Hello.

You may use RTLEvents to pause a thread. =>

Program Project1;
{$mode objfpc}{$H+}
uses
  {$IFDEF UNIX}
  cthreads,
  {$ENDIF}
  Classes;
Type
  { THelloThread }
  THelloThread = class(TThread)
    fSleepTime,fThreadNum:integer;
    fEvent:PRTLEvent;
    procedure Execute; override;
    constructor Create(sleepTime,threadNum:integer);
    destructor Destroy; override;
  end;
var
  ThreadArray:array[1..10] of THelloThread;

{ THelloThread }

procedure THelloThread.Execute;
begin
  while true do
  begin
    writeln('Thread ',fThreadNum,' sleeping for ',fsleepTime,' ms');
    RTLeventWaitFor(fEvent,fSleepTime);
    if Terminated then break;
    //don't forget to reset,
    RTLeventResetEvent(fEvent);
    writeln('Hello From Thread ',fThreadNum);
  end;
  writeln('Bye from ',fThreadNum);
end;
constructor THelloThread.Create(sleepTime,threadNum: integer);
begin
  inherited Create(true);
  FreeOnTerminate := true;
  fEvent := RTLEventCreate;
  fSleepTime := sleepTime;
  fThreadNum := threadNum;
  Start;
end;
destructor THelloThread.Destroy;
begin
  RTLeventdestroy(fEvent);
  inherited Destroy;
end;
procedure CreateThreads;
var
  l:integer;
begin
  for l := low(ThreadArray) to high(ThreadArray) do
    ThreadArray[l] := THelloThread.Create(l*1000,l);
end;
procedure StopThreads;
var
  l:integer;
begin
  for l := low(ThreadArray) to high(ThreadArray) do
  begin
    ThreadArray[l].Terminate;
    RTLeventSetEvent(ThreadArray[l].fEvent); //wake event up for early
terminattion
    ThreadArray[l].WaitFor;
  end;
end;
begin
  CreateThreads;
  writeln('Press Any Key To Stop.');
  readln;
  StopThreads;
  writeln('All threads stopped');
  readln;
end.

-----
Many thanks ;-)

fredvs wrote

Hello. You may use RTLEvents to pause a thread. =>

Obviously CPU the overhead is a lot greater than with just calling sleep.

-Michael

In our previous episode, Michael Schnell said:

> You may use RTLEvents to pause a thread. => > Obviously CPU the overhead is a lot greater than with just calling sleep.

??? Afaik they are the procedural counterpart of TEvents, and I think that using them is cheaper than sleep, since you only unblock when needed.

Marco van de Voort wrote

??? Afaik they are the procedural counterpart of TEvents, and I think that using them is cheaper than sleep, since you only unblock when needed.

??? I _thought_ sleep would just call the appropriate OS function but in fact it does

Function  FpNanoSleep  (req : ptimespec;rem : ptimespec):cint; external
name 'FPC_SYSC_NANOSLEEP';

I don't know what this does.

-Michael

Michael Schnell wrote

I don't know what this does.

With stepping in ASM I verified that (after some calculation) it does just a single syscall (via a "sysenter" Assembler instruction).

so the overhead is minimal.

-Michael

Blocking with an even will sleep until someone wakes you up, it's very efficient. Using sleep() you will have to wake up, check if someone needs you, go to sleep again, etc. This is obviously more inefficient.

Henry Vermaak wrote

Blocking with an even will sleep until someone wakes you up, it's very efficient. Using sleep() you will have to wake up, check if someone needs you, go to sleep again, etc. This is obviously more inefficient.

We were talking about the overhead of a "sleep for n milliseconds" functionality itself, and not about waiting for some event.

Abusing it for polling of course is not what sleep is meant for.

Sleep is for granting the CPU for other processes for (at least) a predefined time.

See the mail of the original poster: this is what he asked for.

-Michael

The message you replied to was regarding pausing a thread, let me quote you back to yourself:

===============================================================================

fredvs wrote

Hello. You may use RTLEvents to pause a thread. =>

Obviously CPU the overhead is a lot greater than with just calling sleep.

-Michael

===============================================================================

This is incorrect, since if you pause a thread with sleep(), you'll have to loop to check when you're supposed to wake up.

Henry Vermaak wrote

Obviously CPU the overhead is a lot greater than with just calling sleep.

..... Regarding the context ;-)

-Michael

2015-02-26 18:50 GMT+08:00 Henry Vermaak :

​Thats ri​ght.

This is incorrect, since if you pause a thread with sleep(), you'll have to loop to check when you're supposed to wake up.

​I use rtlevent, but only meant to maintain a pool of threads, while there is no task for a thread it is blocked waiting for an event.

BUT, that cannot be used to prioritize a thread. While you block a thread using rtlevent, it can only be unblocked from another thread. While you use sleep(), it still get time share of the CPU, only that it does nothing until sleep finishes, right? That way, it only consume a tiny amount of computing power while sleeping. This, in my view, is the price I have to pay to achieve my purpose?

How can a thread decide how it should be scheduled, without any knowledge about the number of other threads and the load of the system?

I still think that doing the scheduling yourself, you'll be fighting against the operating system. If you have threads that are more urgent than others, use the operating system specific method to help the scheduler decide how much CPU time to give a thread.

Henry

In our previous episode, Xiangrong Fang said:

BUT, that cannot be used to prioritize a thread. While you block a thread using rtlevent, it can only be unblocked from another thread. While you use sleep(), it still get time share of the CPU, only that it does nothing until sleep finishes, right?

No, basically a sleeping thread is marked in the scheduler as "do not schedule for nn ticks". The thread doesn't run to evaluate if it should contiue. That is the scheduler/kernel's task.

2015-02-26 21:53 GMT+08:00 Marco van de Voort :

**AUTOMATICALLY** re-scheduled,
without the need of knowledge of other threads/processes running on the system!

​This is the effect of a thread voluntarily gives up its cpu share, but not let other thread to control its "fate". ​

Xiangrong Fang wrote

That's even better.

As said: sleep() does make sense when used for the purpose it's provided for (by the OS). And in that use, it imposes the lowest possible overhead.

-Michael

Looking at the TThread documentation, since Suspend and Resume are deprecated should Suspended be similarly annotated?

Looking at
http://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial#Initialization_and_Finalization there are dire warnings that TThread.Create() shouldn't be overridden. Should this be in the documentation if it's a significant issue?

Sorry about the niggles, I'm currently trying to track down a race condition.

El 28/02/15 a les 20:20, Mark Morgan Lloyd ha escrit:

Looking at http://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial#Initialization_and_Finalization there are dire warnings that TThread.Create() shouldn't be overridden. Should this be in the documentation if it's a significant issue?

It's the first time I hear it, I've been doing it forever, just like in the example in the same wiki page.

Sorry about the niggles, I'm currently trying to track down a race condition.

I doubt it's the cause of your race condition, unless you call the "inherited create(false)" at the beginning of your create, before creating everything else the thread uses.

Bye

Hum... same for me here... ;-(

Do you think it could explain memory leak that i cannot solve even using this ? =>

  constructor TMyThread.Create(CreateSuspended: boolean;
  const StackSize: SizeUInt);
 begin
  inherited Create(CreateSuspended, StackSize);
  FreeOnTerminate := false;  => this not working ?
...
end;

Thanks.

Fred

-----
Many thanks ;-)

Ooops, in previous mail you should read (sorry)=>

Hum... same for me here... ;-(

Do you think it could explain memory leak that i cannot solve even using this ? =>

  constructor TMyThread.Create(CreateSuspended: boolean;
  const StackSize: SizeUInt);
 begin
  inherited Create(CreateSuspended, StackSize);
  FreeOnTerminate := TRUE ;  => (changed) this not working ?
...
end;

Thanks.

Fred

-----
Many thanks ;-)

[...] Looking at http://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial#Initialization_and_Finalization there are dire warnings that TThread.Create() shouldn't be overridden.

That is nonsense. Unless you plan to create arbitrary threads.

That paragraph needs to be fixed.

Mattias

El 01/03/15 a les 22:34, fredvs ha escrit:

I think it could create a memory leak if the thread terminates before the assignment of FreeOnTerminate.
Unlikely (so I'd look somewhere else) but possible, so reverse the sequence, i.e.

  FreeOnTerminate:=True;
  inherited Create

or create the thread suspended then start it as the last instruction in the constructor.
Oh, and be careful if in the section you marked as "..." you do something that the thread needs: it is possible that the thread runs *before* the "..." section. Again, create the thread last or create it suspended and start it at the end of the creator.

Bye

It appears to have been a change put in by "Socke" on the 12th January this year. Does anybody know why he did it?

Mark Morgan Lloyd wrote

Looking at http://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial#Initialization_and_Finalization there are dire warnings that TThread.Create() shouldn't be overridden.

???

The Docs say "Normally you are required to override only 2 methods: the Create constructor, and the Execute method. "

-Michael

Probably some misunderstanding of OOP.
I changed it.

Mattias

Yes, and the docs don't mark Suspended as deprecated, which is one of the reasons I was doing a general compare-and-contrast exercise.

Luca Olivetti wrote

create it suspended and start it at the end of the creator.

Very good advice. I always create them suspended, and never had any serious issues with threads.

Regards,
- Graeme -

Coming back to the initial message, I've had to solve a similar problem a year ago. A bunch of threads had to do do some job each one related to a database. Jobs to do were coming from the main thread (a service) and some results and messages where held and processed by the same main thread. The main problem was that all threads had to take care from incoming messages.

For tthese reasons I implemented the threads with a loop where the last instruction was a WaitForMultipleObjects. The events where hosted and set in the main thread which fired the events when something was to be done by the relevant thread. This way, when the thread had nothning to do, the WaitFor... passed the control to the kernel and entered a sleep state. But if an incoming job was posted, the event fired did awake the corresponding thread. Some other threads did not wait for any external job, so the WaitFor... was replaced by a simple Sleep. This helped me to implement an internal thread safe message queue. Another problem solved was a front end program using Indy and TCP/IP listener using non blocking sockets, to be reactive to more than 20 active TCP/IP clients sending messages for about 10 in a second for each client. The front end program managed all this incoming traffic showing that all client threads were working almost "at the same time". Using events the main program was able to send user commands to the "sleepeng" threads and seeing them be using either Sleep or events depends on what the thread is supposed to do and what are the incoming signals if any. Using Sleep nothing can reach the sleeping thread whilst waiting for events stops the thread until something has to be done. On the other hand a periodical awake period using the WaitFor... timeout.

Antonio.

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. http://www.avast.com