Board index » Visual Studio » thread handler

Visual Studio185
Hi all!



First sorry about my poor english.



I developping a server application which runs as a windows service. At

the beginig I was some problem but they are now solved.

Today I make a notice. I am looking through the log file which was

created by my server. It shows that if I start a thread it always get

the same id.



To be more understable.



I have a static class member function what we call now mainloop.

The declaration is as follow:

void mainloop(void* _ptr);



This function is created by a class function namely: start().

In start I use _beginthread() to spawn the thread.



I call this function (start) once during the service.



Here comes the intresting observation. I always get back the same

handler for the same thread function.

So if i start my service then stop it then start again end stop and so

on than I always will see that the mainloop thread has the same thread

handler.



Why is this?



I thought that the thread id/handler(s) are unique systemwide



And an other little question.



_In beginthread I shall have the ability to control the stack size. If

I want a bigger stack then the default 1MB then it works correctly. But

If I want a smaller for exapmle 128KB then it not working.

(It is just a srtong feeling because I base my opinion on empirical

test to how many threads I can spawn. If I increase the stack size then

I can spawn less threads. For example If I set the stack size to 10 MB

then I can spawn about 196-198 threadand and if I set the stack size

128 kB than I still can spawn just about 2000 thread due to 2GB heap

memory limit/proccess(like with default 1 MB stack size.))



Thans in advance:

Nagyjano


-

Thread handles and thread IDs are guaranteed to be "unique" only as long as the thread

exists. The OS is free to reassign those same values to some other thread if it feels

like it. So it is not surprising to see these reappear. In fact, I've seen the same

thread ID reappear within a single execution; as threads are destroyed and re-created.



You are correct in observing that the number of threads you can spawn is correlated to the

stack size. But when you say "it doesn't work", you need to say a bit more about what

that means. Note that 128K is a bit small, particularly if you have lots of local space

allocated on the stack.



In general, spawning that many threads makes everything run slower, so you need a good

justification for using that many threads. Your program will *not* run faster with 2000

threads unless you are on something like a 1000-processor system. Right now the maximum

number of processors for Win32 is 32 and for Win64 is 64, so you should be thinking about

the design fairly carefully.

joe



On 5 Oct 2006 07:04:08 -0700, "Nagyjano" <nagyjano@gmail.com>wrote:



email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-

Hi!



Thanks for your answer.



About the thread handlers:

I think than it is normal if I get the same handler for the same

function in the same process in execution after execution.



About threads number.

In fact my server application have to serve only about 200-400

connections at the same time on full use, but generally it serves about

40-100 connection at the same time. It was just a test to how many

connections can be served simultaneously.

But to demonstrate my problem I wrote a simple demo. You will be able

to download it from the address below:

nagyjano.anyanyelvapolo.hu/programs/threaddemo/">nagyjano.anyanyelvapolo.hu/programs/threaddemo/



The usage I think quite simple :)



So If I set the stack size to 8*1024*1024 then I can create about 244

thread

If I set the stack size to 0 (same as 1024*1024) than I can creat about

2000 thread (at me it is 2003)

But if I set the stack size 256*1024 (or 128*1024) then I can create

again just about 2000 (at me 2003) threads. (and not about 8000 as I

expected)



Maybe there are a compiler flag what shall be set?



About design questions.

Why threads? Because it is simple to separate the things on this way :)

I think a system with 1000 processor maybe a bit over our requirements,

but a system with 32 or 64 processor is just perfect. I made some test

on a machine with a single porcessor and with just 1GB memory but is

worked fine. In real use it will run on a server with 2 Xeon processor

and with 2GB memory and a lots of disk space on a WinServer2003.

(Storing files and update a database are the primary objectives. They

add files and sometime they want a copy about it back :) )

In the future the hardware can be upgaded whenever it is necessary.

So now I would say it can handle about 300-400 connection at the same

time with a very high stability.



Oh, I forgot to say I use MSVC++ (6.00) and WinXp



Best regards,

Nagyjano



-

You shouldn't be using a thread per connection. Such design is broken. Use

asynchronous sockets or IOCP.



A thread reserves about 1M for stack, and also some memory in the kernel.



"Nagyjano" <nagyjano@gmail.com>wrote in message



-

I've used one-thread-per-connection when I was using a very small number of

connections...we would have perhaps a max of ten connections. But for 200-400 connections

such a design does not scale well. I agree; for something of this size, using

CAsyncSocket would be a much better approach.

joe



On Fri, 6 Oct 2006 21:02:53 -0700, "Alexander Grigoriev" <alegr@earthlink.net>wrote:



email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-

Hi!



Thanks for the answers and help.

I will look at this CAsyncSocket.

Its behaviour can be simulated by simple socket functions? (socket,

bind, accept, listen, sendto, recvfrom, send, recv??)



Best regards,

Nagyjano



-

Nagyjano wrote:

Yes, CAsyncSocket uses all of those functions in a nonblocking socket

mode. See WSAAsyncSelect for the underlying basic concept: It uses this

to put the socket in a mode that will generate a windows message to

notify you of all socket events. Then the window message is converted

into virtual methods of CAsyncSocket, which you override.



--

Scott McPhillips [VC++ MVP]



-

Thanks I will check it.



Nagyjano



-

Yes, but there is little to be gained by trying to "roll your own". WSAAsyncSelect is the

key API function, but after that life gets complicated.

joe



On 10 Oct 2006 03:31:52 -0700, "Nagyjano" <nagyjano@gmail.com>wrote:



email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-