General thread question

[Jim Stools]

Newbie question: Hopefully I worded this correctly...

Does each instance of an aspx page spawn its own thread? If so are the
threads protected? I assume each aspx page is processed in a synchronized
method and each instance has to finish processing before the next instance
is queued? If an aspx page has a class that requires lengthly processing are
all other instances of the page queued. If more than one aspx page uses the
modFoo class (simple sample before) would I be headed for trouble?

public class modFoo
{
public static Int32 lClient = 0;

public modFoo()
{
}
}

 

[olrt]

Does each instance of an aspx page spawn its own thread?
ASP.NET dispatches pool threads as the load of requests increase.
(Process ASPNET_WP.EXE).
Generally there's a maximum pool size so a page doesn't always spawn a
new thread.
A page is processed by a worker thread that may already have been
launched before (that is called thread pooling).

I assume each aspx page is processed in a synchronized
method

A page is totally processed by only one thread.
So the question is no use.

If an aspx page has a class that requires lengthly processing are
all other instances of the page queued

With IIS sure and fortunately ! Again that is thread pooling that
enables parallelizing page processing.
With personal WebServer not sure.

If more than one aspx page uses the
modFoo class (simple sample before) would I be headed for trouble?

public class modFoo
{
public static Int32 lClient = 0;

public modFoo()
{
}
}

If each page instantiate a modFoo object, there'll be multiple threads
that will share IClient member so'll have to synchronize access to it.
If you want each thread have it's own copy of IClient, you should write
:

[ThreadStaticAttribute]
public static Int32 lClient = 0;


But it might not be what you want.

 

[Jim Stools]

Exactly what I wanted..Thanks

Does each instance of an aspx page spawn its own thread?

ASP.NET dispatches pool threads as the load of requests increase.
(Process ASPNET_WP.EXE).
Generally there's a maximum pool size so a page doesn't always spawn a
new thread.
A page is processed by a worker thread that may already have been
launched before (that is called thread pooling).

I assume each aspx page is processed in a synchronized
method

A page is totally processed by only one thread.
So the question is no use.

If an aspx page has a class that requires lengthly processing are
all other instances of the page queued

With IIS sure and fortunately ! Again that is thread pooling that
enables parallelizing page processing.
With personal WebServer not sure.

If more than one aspx page uses the
modFoo class (simple sample before) would I be headed for trouble?

public class modFoo
{
public static Int32 lClient = 0;

public modFoo()
{
}
}

If each page instantiate a modFoo object, there'll be multiple threads
that will share IClient member so'll have to synchronize access to it.
If you want each thread have it's own copy of IClient, you should write
:

[ThreadStaticAttribute]
public static Int32 lClient = 0;


But it might not be what you want.

 

[Jim Stools]

Why do you say "But it might not be what you want"? Do you have another
thought?

I also assume this would accomblish the same thing and have the same problem
(without [ThreadStatisAttribute]):


public class modFoo
{
private Int32 lClient = 0;

public modFoo()
{
}

public Int32 Client
{
get { return lClient; }
put { lClient = value; }
}
}

Does each instance of an aspx page spawn its own thread?

ASP.NET dispatches pool threads as the load of requests increase.
(Process ASPNET_WP.EXE).
Generally there's a maximum pool size so a page doesn't always spawn a
new thread.
A page is processed by a worker thread that may already have been
launched before (that is called thread pooling).

I assume each aspx page is processed in a synchronized
method

A page is totally processed by only one thread.
So the question is no use.

If an aspx page has a class that requires lengthly processing are
all other instances of the page queued

With IIS sure and fortunately ! Again that is thread pooling that
enables parallelizing page processing.
With personal WebServer not sure.

If more than one aspx page uses the
modFoo class (simple sample before) would I be headed for trouble?

public class modFoo
{
public static Int32 lClient = 0;

public modFoo()
{
}
}

If each page instantiate a modFoo object, there'll be multiple threads
that will share IClient member so'll have to synchronize access to it.
If you want each thread have it's own copy of IClient, you should write
:

[ThreadStaticAttribute]
public static Int32 lClient = 0;


But it might not be what you want.

 

[olrt]

If you code :
public class modFoo
{
private Int32 lClient = 0;

public modFoo()
{
}

public Int32 Client
{
get { return lClient; }
put { lClient = value; }
}
}

Each page served has it's own IClient ...


If you code :
public class modFoo
{
[ThreadStaticAttribute]
public static Int32 lClient = 0;

public modFoo()
{
}
}

each thread has its own IClient...

That's different...

Suppose there are two worker threads (Th1 and Th2) that serve the page.
Suppose
Th1 serves client1, client2, client3
Th2 serves client4

With [ThreadStaticAttribute] and static modifier :
Th1 and Th2 have their own IClient.

Without :
client1, client2, client3, client4 have their own IClient.

 

[Jim Stools]

Thanks...very much for explanation