Re: Can extra processing threads help in this case?
Good example Jerry. I would of done a few things differently.
First, The critical section skews the scheduling for the threads,
preferencing the higher priority threads. Removing it provides a
closer measurement of natural quantum based time slicing and you get
different results.
Second, I would get the baseline count rates (msecs/count increment)
for equal priority threads, then change the priority of one to
compare rate differences.
I would also note that the for loop is a simulation of natural
quantums. i.e. add some simulation of "system interrupts", like a
sleep(0) or sleep(1) to get the preemption and as you know we should
see different results. This is often a critical thing to remember
when usuing higher priority threads. They should be more computational
and less introducing even more interrupts. So if his higher priority
job thread is updating SQL database, logs, saving result to disk, it
will most likely hurt his system performance.
Here is what I changed it to, to move the results after the threads
are done, analyze even higher threads to see how it alter things.
// warning: this is intended purely to demonstrate one simple point,
// not as particularly exemplary multithreaded code.
#include <windows.h>
#include <iostream>
#include <process.h>
#include <conio.h>
#include <Mmsystem.h>
#pragma comment(lib,"Winmm.lib")
const DWORD THREAD_WORK_TIME = 1000*15;
const DWORD MAX_THREADS = 2;
//------------------------------------------------------
// Thread data to keep timing stats
//------------------------------------------------------
typedef struct _tagTThreadData {
DWORD index;
DWORD dwStartTime;
DWORD dwEndTime;
DWORD dwTimes;
DWORD dwCount;
} TThreadData;
TThreadData ThreadData[MAX_THREADS] = {0};
unsigned int __stdcall threadproc(void *p) {
timeBeginPeriod(1);
TThreadData *pd = (TThreadData *)p;
pd->dwStartTime = GetTickCount();
while (GetTickCount() - pd->dwStartTime < THREAD_WORK_TIME) {
// burn some CPU time so we're usually ready to run:
DWORD t1 = GetTickCount();
//Sleep(1);
//Sleep(0);
for (int i=0; i<10000000; i++);
DWORD t2 = GetTickCount();
pd->dwTimes+= (t2-t1);
pd->dwCount++;
}
pd->dwEndTime = GetTickCount();
timeEndPeriod(1);
return 0;
}
int main()
{
ZeroMemory(&ThreadData,sizeof(ThreadData));
HANDLE hThreads[MAX_THREADS] = {0};
_cprintf("* Creating %d threads\n",MAX_THREADS);
// create a couple of threads:
int i;
for (i=0; i < MAX_THREADS; i++) {
ThreadData[i].index = i;
hThreads[i] = (HANDLE)_beginthreadex(
NULL,
0,
threadproc,
(void *)&ThreadData[i],
CREATE_SUSPENDED,
NULL);
// and make sure they run on the same processor/core
SetThreadAffinityMask((HANDLE)hThreads[i], 1);
}
// reduce priority of one thread:
//SetThreadPriority((HANDLE)hThreads[0],
THREAD_PRIORITY_ABOVE_NORMAL);
SetThreadPriority((HANDLE)hThreads[0], THREAD_PRIORITY_IDLE);
_cprintf("* Resuming threads\n");
for (i=0; i<MAX_THREADS; i++) {
ResumeThread((HANDLE)hThreads[i]);
}
_cprintf("* Wait For Threads Completion\n");
WaitForMultipleObjects(MAX_THREADS, (HANDLE *)hThreads, true,
INFINITE);
_cprintf("* DONE. RESULT\n");
for (i=0; i<MAX_THREADS; i++) {
TThreadData td = ThreadData[i];
double f = 1.0*td.dwTimes/td.dwCount;
printf("thread# %4d | cnt: %9d | time: %9d | time/cnt: %9.4f
\n",
i+1,
td.dwCount, td.dwTimes, f);
}
return 0;
}
--
HLS
On Apr 12, 9:10 pm, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
In article <GtSdnVtJ8-u84F7WnZ2dnUVZ_rWdn...@giganews.com>,
NoS...@OCR4Screen.com says...
[ ... ]
That sure sounds screwy to me. Of the 40 different priority
levels available on Linux, a process with priority of 0
would starve a process with priority of 1? That sure sounds
screwy to me. Can you prove this?
With a few provisos, yes. First proviso: if you have (for example)
two threads and two cores, both threads will run concurrently.
Second, Linux has a "dynamic priority" range (sort of like Windows)
where it adjusts the base priority as it sees fit, and in this range,
the scheduler may override the base difference of 1.
Outside that range, yes, even the smallest possible difference in
priority will make the difference between getting essentially all the
processor time, and virtually none at all (though if you have two or
more at the same priority, processing time will normally be split
roughly evenly between them). Windows works roughly the same way.
Here's a simple demo program:
// warning: this is intended purely to demonstrate one simple point,
// not as particularly exemplary multithreaded code.
#include <windows.h>
#include <iostream>
#include <process.h>
CRITICAL_SECTION s;
unsigned int __stdcall threadproc(void *p) {
int line = (int)p;
COORD pos;
pos.X=0;
pos.Y=(short)p;
DWORD start = GetTickCount();
int count = 0;
HANDLE output = GetStdHandle(STD_OUTPUT_HANDLE);
// run test for 15 second:
while (GetTickCount()-start < 15000) {
// burn some CPU time so we're usually ready to run:
for (int i=0; i<10000000; i++)
;
// print out how often we've run:
EnterCriticalSection(&s);
SetConsoleCursorPosition(output, pos);
printf("%d", ++count);
LeaveCriticalSection(&s);
}
return 0;
}
int main() {
uintptr_t handles[2];
InitializeCriticalSection(&s);
// create a couple of threads:
for (int i=0; i<2; i++) {
handles[i] = _beginthreadex(NULL,
0,
threadproc,
(void *)(i+6),
CREATE_SUSPENDED,
NULL);
// and make sure they run on the same processor/core
SetThreadAffinityMask((HANDLE)handles[i], 1);
}
// reduce priority of one thread:
SetThreadPriority((HANDLE)handles[1], THREAD_PRIORITY_IDLE);
// Let them run:
ResumeThread((HANDLE)handles[0]);
ResumeThread((HANDLE)handles[1]);
// and wait 'til they're done:
WaitForMultipleObjects(2, (HANDLE *)handles, true, INFINITE);
std::cout << "\n\n";
return 0;
}
Running this, I get a count of ~500 for one thread, and 2 or 3 for
the other thread (I.e. the lower priority thread getting somewhere
around half a percent of the CPU time). Changing the exact difference
in priority such as setting to THREAD_PRIORITY_LOWEST or
THREAD_PRIORITY_BELOW_NORMAL has little (if any) real effect on the
amount of CPU time -- it might get it up to 1 whole percent of
processor time instead of a half, but I'm not sure it really makes
any difference at all -- showing that on thread gets two orders of
magnitude more processor time than the other is a lot simpler than
determining with certainty whether a possible difference between .6%
and .8% (for example) of the processor time is statistically
significant.
What I am saying is that telling me that it is bad without
telling me what is bad about it is far worse than useless.
In more than half of the cases now what was bad about my
design was not the design itself but the misconception of
it. Without explaining why you think it is bad, and only
saying that it is bad is really harassment and not helpful.
And what I'm saying is that if you won't bother doing some homework
to learn at least a *little* bit on your own, it's frankly rather
insulting that you constantly ask others to not only give you the
results of the work you should have done, but then turn around and
question their intelligence or honesty and demand proof of results
simply because they don't fit how you imagined things might be.
[DoS attacks]
So what else can be done, nothing?
Of course something can be done. I've already pointed out part of the
task -- get rid of the thread-per-connection model that's so
dangerous. That's roughly the equivalent of advising that when you're
going on a trip that 1) you lock the door before you leave, and 2)
refrain from going to the local hoodlum's hangout and announce to all
who will listen that you're going to be gone, and you're leaving the
door unlocked, and oh, yes, you've got just the most incredible
stereo equipment that'll just be theirs for the taking if they show
up next week!
--
Later,
Jerry.