comp.lang.ada
 help / color / mirror / Atom feed
* A Simpler Find Tool
@ 2017-05-21  5:04 Brian Kolden
  2017-05-21  6:49 ` Simon Wright
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Brian Kolden @ 2017-05-21  5:04 UTC (permalink / raw)


I made a simple find tool for Linux, https://github.com/bkold/finda, and I was wondering if I could optimize the task scheduling a bit. 

	protected body Task_Pool_Status is
		procedure Check (Thread_Pointer : out Thread_Access) is
		begin
			for I in Status'Range loop
				if Status(I) = Ready then
					Status(I) := Working;
					Thread_Pointer := Threads(I);
					return;
				end if;
			end loop;
			Thread_Pointer := Null;
		end Check;

		procedure End_Thread (Thread_Num : in CPU) is
		begin
			Status(Thread_Num) := Ready;
		end End_Thread;
	end Task_Pool_Status;

I'm using a request and reserve model to determine which threads are waiting and which are busy. The threads call End_Thread when they finish their work in order to be available to be queued again. I think the model itself is good, but I was unhappy with how I find the sleeping threads. Does anyone have a cleaner suggestion?


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: A Simpler Find Tool
  2017-05-21  5:04 A Simpler Find Tool Brian Kolden
@ 2017-05-21  6:49 ` Simon Wright
  2017-05-22  3:19   ` Brian Kolden
  2017-05-21  9:44 ` G.B.
  2017-05-21 17:22 ` Jeffrey R. Carter
  2 siblings, 1 reply; 5+ messages in thread
From: Simon Wright @ 2017-05-21  6:49 UTC (permalink / raw)


Brian Kolden <bakolden5@gmail.com> writes:

> I made a simple find tool for Linux, https://github.com/bkold/finda,
> and I was wondering if I could optimize the task scheduling a bit.
>
> 	protected body Task_Pool_Status is
> 		procedure Check (Thread_Pointer : out Thread_Access) is
> 		begin
> 			for I in Status'Range loop
> 				if Status(I) = Ready then
> 					Status(I) := Working;
> 					Thread_Pointer := Threads(I);
> 					return;
> 				end if;
> 			end loop;
> 			Thread_Pointer := Null;
> 		end Check;
>
> 		procedure End_Thread (Thread_Num : in CPU) is
> 		begin
> 			Status(Thread_Num) := Ready;
> 		end End_Thread;
> 	end Task_Pool_Status;
>
> I'm using a request and reserve model to determine which threads are
> waiting and which are busy. The threads call End_Thread when they
> finish their work in order to be available to be queued again. I think
> the model itself is good, but I was unhappy with how I find the
> sleeping threads. Does anyone have a cleaner suggestion?

Just how many threads are you expecting to have? Is it worth saving some
cycles here?

You could have a queue of Ready threads, pop a thread when required,
push when done. That would allow you to have an entry, which would save
the polling?

   entry Get (A_Thread : out Thread_Access) when Queue.Head /= null
   is

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: A Simpler Find Tool
  2017-05-21  5:04 A Simpler Find Tool Brian Kolden
  2017-05-21  6:49 ` Simon Wright
@ 2017-05-21  9:44 ` G.B.
  2017-05-21 17:22 ` Jeffrey R. Carter
  2 siblings, 0 replies; 5+ messages in thread
From: G.B. @ 2017-05-21  9:44 UTC (permalink / raw)


On 21.05.17 07:04, Brian Kolden wrote:
> Does anyone have a cleaner suggestion?

Not answering directly, but did you have a look at how
the Paraffin library handles this? (Available at
BIZX Company's SourceForge subsidiary.)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: A Simpler Find Tool
  2017-05-21  5:04 A Simpler Find Tool Brian Kolden
  2017-05-21  6:49 ` Simon Wright
  2017-05-21  9:44 ` G.B.
@ 2017-05-21 17:22 ` Jeffrey R. Carter
  2 siblings, 0 replies; 5+ messages in thread
From: Jeffrey R. Carter @ 2017-05-21 17:22 UTC (permalink / raw)


On 05/21/2017 07:04 AM, Brian Kolden wrote:
>
> I'm using a request and reserve model to determine which threads are waiting
> and which are busy. The threads call End_Thread when they finish their work
> in order to be available to be queued again. I think the model itself is
> good, but I was unhappy with how I find the sleeping threads. Does anyone
> have a cleaner suggestion?

This feels backward to me. In Ada, tasks schedule themselves, so it seems more 
natural for the task to wait until there's work to do and then do it than for 
the work to look for an available task.

I'd suggest you replace your task pool with an instance of PragmARC.Job_Pools.

The PragmAda Reusable Components are available from

https://pragmada.x10hosting.com/

and

https://github.com/jrcarter/PragmARC

-- 
Jeff Carter
"I soiled my armor, I was so scared."
Monty Python & the Holy Grail
71

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: A Simpler Find Tool
  2017-05-21  6:49 ` Simon Wright
@ 2017-05-22  3:19   ` Brian Kolden
  0 siblings, 0 replies; 5+ messages in thread
From: Brian Kolden @ 2017-05-22  3:19 UTC (permalink / raw)


> Just how many threads are you expecting to have? Is it worth saving some
> cycles here?

It's being called almost constantly, so yes.
 
> You could have a queue of Ready threads, pop a thread when required,
> push when done. That would allow you to have an entry, which would save
> the polling?
> 
>    entry Get (A_Thread : out Thread_Access) when Queue.Head /= null
>    is

I don't know why I didn't think to do that. It's using a stack now.


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2017-05-22  3:19 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-21  5:04 A Simpler Find Tool Brian Kolden
2017-05-21  6:49 ` Simon Wright
2017-05-22  3:19   ` Brian Kolden
2017-05-21  9:44 ` G.B.
2017-05-21 17:22 ` Jeffrey R. Carter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox