Re: Jobs or Threads?

Fred,

There are no files or shared resources.  Each thread creates
a new socket connection to a server.  After each socked
ends, an entry to a HashTable is added with the time it took
to make and receive the request.

I'm getting very mixed results with response times with
threads vs. jobs.  They are way off of each other in some
case, and very close in others.

It's something like this:

do 50
  saveStartTime
  makeRequesttoServer("foo");
  saveEndTime
enddo

If inside the loop I create jobs vs. threads to make the
request, I'm getting mixed results, mainly on the first job
I run.

If the request forces a new server instance to start on the
remote side, I get very different results when using threads
vs. jobs for the request.  Threads actually produce better
response times from the server by 4x or more.

Brad

On Tue, 26 Feb 2002 10:59:36 -0600
 Fred Kulack <kulack@us.ibm.com> wrote:
>
> Sort of depends... The word 'application' in your
> question worries me
> (but only because it can mean so many different things).
> If you're thinking of running a whole application
> multiple times, then
> a new job is what you want.
> However, for smaller, encapsulated pieces of work, then a
> thread
> may fit your design.
>
> So the real question is:
>   Can your application stand in the same job as another
> instance
> of itself running without negatively effecting the shared
> resources
> that you get in a threaded environment?
> I.e. all open files would be shared, locks would be used
> to protect
> access in certain cases (many of which may be your
> responsibility),
> global and statidc storage would be shared, etc).
>
> Threads versus Jobs which are better depends entirely on
> the
> problem/solution and the code used to implement it.
>
>