1

i am trying to implement a new scheduling technique with Multithreads. The idea is, each time the task is created from the program thread, it should search the worker threads and work on the Thread which is least busy among the Threads.

Can you suggest some logics (or) idea how to find the least busy thread, among the given threads dynamically in programming point of view

I am working in C++ programming language.

aram
  • 71
  • 1
  • 10
  • Scheduling is something that your threading library/implementation should do that for you implicitly. Not sure what you exactly qualify's as *least busy*. – Alok Save Jan 03 '13 at 15:57
  • Windows, completion ports? Linux, epool? Cross platform: boost asio? Microsoft PPL? Intel TBB? – joy Jan 03 '13 at 16:00
  • At any given point, threads are typically busy or not. "Least busy" is not a real concept. You can of course measure which thread was least busy in the past, but that's not a useful measure when their workloads change dynamically as you suggest here. – MSalters Jan 03 '13 at 16:06
  • @neagoegab i am working in linux platform in our own library written in c++. The library uses c++ templates heavily. – aram Jan 03 '13 at 16:10

2 Answers2

0

I imagine that you have a workhorse function that does the job on each thread. You could define a thread-local variable that you increment each time this function is called. This variable will show, for the corresponding thread, how much work it has done.

Then, the program thread will check and compare those values before dispatching the task at hand to the selected thread (the one with minimal work-counter).

Another way would be to use a measure of time spent in work/time spent in idle for each thread. Work-time is considered between the beginning and the end of the thread's workhorse function, while idle time is the other one (you could measure all of those at the beginning and the ending of the workforce function).

Anyway, the idea is that basically each work-thread will measure how much occupied it is. This is somewhat imprecise, but more advanced solution will basically involve re-creating a threading library/framework.

user1284631
  • 4,446
  • 36
  • 61
  • @axeothSorry for late reply, i think the thread local variable idea would do good. And the time idea, i couldnt understand properly. How is the work time,ideal time calculated? and are the tasks are allocated to thread which has more idle time? – aram Jan 04 '13 at 09:22
  • I think you could read the current CPU time at the beginning of the workhorse function and store it into a variable. Then, at the end of the workhorse function, you read again the CPU time and store it into another variable. The difference between the two is how long the function spent in computation (workload). – user1284631 Jan 04 '13 at 10:25
  • @axeothIn the thread local variable idea, the program thread just sees the thread local variable counter and dispatch to thread which has minimal counter. But the problem we dont know how much time each tasks takes to complete. ie. the thread variable may have minimal counter, bt the task may be still operating, on the other hand the thread may have higher value counter, but the tasks may be completed very soon. any idea to solve this problem? – aram Jan 08 '13 at 10:34
  • @rahul: first, for solving the busy/nonbusy problem, you could use a supplimentary flag that is set to 0 when the workhorse function exit (the thread is "idle"). for the processing time, I assumed that the tasks performed by the threads are somewhat equivalent. If this is not the case, then probably you should use the time spent in computation, that is, the second idea. – user1284631 Jan 08 '13 at 13:03
  • @axeothI still have doubt in your 2nd idea, couldnt understand it properly By measuring the computation time, how could one identify whether the thread is less busy or not, dynamically? could you please explain it with an simple logic or example – aram Jan 08 '13 at 14:53
  • @rahul: The hypothesis that I made: the thread has a workhorse function, that is called more or less often, with some pause in between those calls. Consequently, the thread will spend some time in computation (in the workhorse function), and some time as idle. Both these times are measurable as described. Their ratio gives how busy that thread is. It is true that this is only a measure for the past history of that thread, but you could extrapolate it to present. So, normally you would choose the thread that is idle (see the flag) now and that has the largest ratio idle_time/busy_time. – user1284631 Jan 08 '13 at 15:04
  • @axeotNow i got cleared how it done, thank you but is it a good idea by seeing the thread history and extrapolating it to present, in a dynamically changing process? – aram Jan 08 '13 at 15:25
  • @rahul: well, that's truly a debatable point. OTOH, at the present time (ie. when you do the check), you have a bunch of several idle threads that are available. Except their past history or some crystal ball to predict the future, you could, in theory, pick *any* of those *idle* threads. OTOH, I tried to imitate the decision that a processor takes when it is about to discard its cache data: it uses the sole information that has: past history. Yes, history does not predict the future, but is the only info you can have. – user1284631 Jan 08 '13 at 15:44
  • @axeothYes thats a truly debatable point,but may be i can try it and implement it and compare it with the results. Thanks much for your interaction. – aram Jan 08 '13 at 15:54
0

The easiest solution is to make a pool of tasks to be picked up. In the idle loop of each thread, check that taskpool. A thread which is busy a lot won't be idle often, therefore not check the taskpool that often, and pick up few additional tasks.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • so is it like making a global queue, and the idle threads checking it often!! – aram Jan 03 '13 at 16:18
  • Well, probably not that often. If an idle thread finds the pool empty, it should block until a new item is added. No need to waste CPU resources. – MSalters Jan 03 '13 at 16:20
  • so it is like idle thread should be blocked, until new tasks are added to the task pool.? – aram Jan 03 '13 at 16:24
  • That's the way threadpools are usually done, yes. Explicitly micro-managing thread instances in a list, and other such approaches, have a tendency to just screw up totally. – Martin James Jan 03 '13 at 19:21