Re: accessing servlet filters

From: eti (eti_antoniutti_at_mac.com)
Date: 11/19/03 

Date: 19 Nov 2003 01:15:47 -0800

Dear William,

> > Yap, of course !
> > Performance is of great concern. I think that sinchronized operations
> > to write a context variable or a sensor variable in a high concurrent
> > environment, would be a bottleneck and jam the system.
>
> How did you come to that conclusion? Did you actually measure it?
> There are so many other time consuming things going on in the
> servlet environment that I doubt you could detect the effect of
> synchronizing this very fast operation.

I did the following:
- given a high number of threads, i.e. 100;
- given an object with a synchronized method accessed concurrently by
the above threads;
- that method implements a sleep, randomly set between 5 to 10 ms;

Result;
- the overall latency due by all concurrent threads accessing the
object synchronized method grows with the number of accessing threads,
well far beyond 100 ms, that is more that 10 times the espected time
to execute the very same method with no synchronization constraints !
As I can suppose this is due to the "long" queue of all threads
waiting to access that method: they are all queued up becaue of the
synch lock, and they need to wait previous threads to release it
before accessing the object synch method.

Notice that in the same context with the same object but with NO
synchronization on that method, the overall latency of all accessing
threads is as aspected: the mean value of the random sequence of sleep
timeouts, between 5 and 10 ms !! -:)

Now in our filter sevlet context: the filters are the concurrent
threads that access a webapp context synchronized variable or a
"sensor" synchronized method to store their current latency value.
They are all queued up and the overall latency, as perceived by the
client, would be excessively high !!!!

On the other hand, if I can act in a reverse fashion and access from
my sensor the actual existing filter threads to read in their "latency
field", NO synchronization is needed. The problem is just that I have
to know at any given (sampling) time the curren number and istances of
the spawned filter threads.

Regards
Etienne

Relevant Pages

  • Re: Synchronization Vs Concurrency
    ... >> Synchronization is one tool used in concurrent programs to ensure ... >> data integrity for data shared by several concurrent tasks. ... >> Asynchronous communication often takes the form of signals. ...
    (comp.programming)
  • Re: Executing a method in a given thread context
    ... As you knoiw, when the callback is run, it is in the context of a ... event in the context of the thread which called Socket.BeginReceive at the ... delivering the message within the correct synchronization context by ... Microsoft Online Community Support ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Synchronization Vs Concurrency
    ... >> I have often heard about synchronization and concurrency being talked ... > data integrity for data shared by several concurrent tasks. ... > Asynchronous communication often takes the form of signals. ...
    (comp.programming)
  • Re: "The Problem with Threads" - IEEEs Computer magazine article
    ... Concurrent Description Language. ... coordination logic (synchronization and communication) is ... 'event operators' and each individual circuit is likely to contain ...
    (comp.programming.threads)
  • ContextBoundObject and [Synchronization]: what calls are from another context?
    ... My understanding is that calls to ContextBoundObjects are checked to see whether the caller is from the same context, and if not, the context rules determine how the call is made. ... For objects with the attribute, the context rules make sure that the caller holds some kind of synchronization object to ensure that only one caller at a time can access objects in the context. ... I thought that BeginInvoke would use a background thread to call the method, and that the calls would come from another context, thus having to take the context lock before proceeding. ... static void Main ...
    (microsoft.public.dotnet.framework.remoting)