Re: Jobs or Threads?

DISCLAIMER: These numbers are very much approximations from one
particular release under one particular circumstance, and even then I
may be misremembering them. I do not have the numbers in front
of me and cannot immediately recreate.

Ok. From some of the testing we have done in the past here's what I recall:
o    Thread creation and waiting for the thread (ignoring the started
thread's
     runtime iteself) about 32,000 RISC instructions and doesn't vary too
much.

o    Job creation takes somewhere between 350,000 and >1,000,000 RISC
     instructions depending on what mechanism you're using to start the
job.
     i.e. spawn is relatively lightweight because it simply copies lots of
     stuff from parent to child. But spawn can inherit descriptors and
other
     stuff making it more expensive. SBMJOB is relatively heavy.
     Adding various jobq, jobd and other stuff to modify behavior
     adds more.

Ultimately however, the choice of using jobs or threads does not
really come down to these measurements.
WHY? Because, in any server that is more than a toy, you should be
pooling threads or jobs (whichever you use) just like you pool JDBC
connections.

o    A pool of threads or jobs waiting for work from a queue.
     Enqueue work onto the queue and dispatching the thread/job using a
     condition variable can be 1000 or LESS RISC instructions if you
optimize it.
     i.e. lock a mutex, enqueue data on shared list, signal condition
variable to wake
     the child thread/job, unlock mutex.
     This is REAL cheap.

It really comes down to things like how much shared data there is between
the tasks, how much locking contention there is between the tasks
(from both an application and OS perspective).
And of course, what the overall architecture, application management
requirements, and system memory utilization of your whole environment needs
to look like.

>From your description it sounds like you're not sharing much between the
tasks.
Without knowing more details, that sounds relatively well suited for
threads.
The backend server is probably written using processes?
In that case, the threaded client would probably go faster than the server.



In every single ethnic, religious or racial group, there are a
very few truly evil people. For each of those people there
are many, many, many good people.
Assuming anything (evilness or capability for evil) about the
particular group is bigotry and idiocy. Don't do it.  -- Me

Fred A. Kulack  -  IBM eServer iSeries - Java DB2 access, Jdbc, JTA, etc...
IBM in Rochester, MN  (Phone: 507.253.5982   T/L 553-5982)
mailto:kulack@us.ibm.com   Personal: mailto:kulack@magnaspeed.net
AOL Instant Messenger: Home:FKulack  Work:FKulackWrk