On 5/10/06, Francis Cianfrocca <garbagecat10 / gmail.com> wrote:
> It's rarely a good idea to modify the priorities of threads in Unix systems.
> Almost all thread-schedulers will never schedule a thread if there is at
> least one runnable thread with a higher priority, which explains the results
> you describe. Your lower-priority threads will basically only get scheduled
> when they're lucky enough to find the highest-priority thread non-runnable.
> If you mess with priorities, you also face the risk of priority inversions,
> where a high-priority thread requires a resource held by a lower-priority
> thread, and they lock each other.
>
> Keep it simple. Sounds like the semantics of your application is to simulate
> users working at different rates. There's nothing there that implies a
> dependence among the threads. I'd use random sleep intervals.

Thanks. I'll probably have a command put together a list of
"micro-tasks" and "execute" each one with a random sleep afterwards.
Not too bad.

Like so:

def command_ls(processorLoad)
	microCommands = [] << makeReadDiskMicroCommands(10)

	filesText = getFiles.join("\n")
	microCommands = << filesText.makeWritelineMicroCommands

	loop do
		doMicroCommand(microCommands.shift)
		sleep(rand(processorLoad))
		break if microCommands.empty?
	end
end