Re: Miltu-core CPUs, threads vs AST driven approaches
- From: "Richard Maher" <maher_rj@xxxxxxxxxxxxxxxxxx>
- Date: Fri, 5 May 2006 18:49:12 +0800
Hi JF,
When it comes to the topic of "ASTs -vs- Threads" I have made my personal
prejudices (all be they founded on fact) abundantly clear here, and in other
forums, on many occasions. But I think most people end up agreeing that, as
with a whole lot of questions, the answer is "It depends" on what your
application is to achieve. If it's a calculation server then maybe threads
is the way to go, but I contend that with most commercial application
requirements, a server system design founded on the backbone of an
AST-threaded Communication server is definitely the way to go. (But then I
would say that wouldn't I :-)
Here are a couple of considerations off the top of my head: -
1) Not everything is thread-safe! If your server is to use Rdb, for
instance, then it simply can't work with threads
2) If you have to stop all threads to mutex around something as mundane as
ADD 1 TO CXN_CNT then what's the point?
3) Only one thread can be in inner-mode at a time, so if you're using RMS or
UWSSs then be aware
3a) Interesting titbit is that inner-mode ASTs are delivered to the thread
that is(if) already in inner-mode. What if there's a user-mode AST active in
another thread? How does that get stopped?
4) Not that anyone here loves Microsoft but, NT's had a big move away from
threads to Asynchronous Callbacks
5) Threads are impossible to debug!
6) It's just all too hard! They're crap and I don't like 'em :-)
So IMHO, if you want something to look after your mouse while your
soundtrack and video is being processed by something else then go threads.
If you want some poorly-written UNIX crap to be ported to VMS then support
threads. In all other cases uses ASTs.
Having a single threaded AST-based server process on a 128 CPU machine
won't be able to make use of 128 CPUs and will use only one. Right ?
Well, yes. If you insist on making the question that narrow then "Yes". But
then no one does that do they? No one says "If I have to hop to work then I
won't get there on time. Right?".
You have the single threaded AST-based server process allocate the-work to a
pool of "n" single-threaded Execution Server processes. VMS will happily
spread these Execution Server processes over all of the available CPUs as an
when it seems fit.And, if you really want, you can use CPU affinity to
dedicate one CPU just to your AST-based Communication Server or any
combination of the above. Any inter-process communication is possible and I
rely heavily on mailboxes. Some will contend that that is soooo much slower
then the communication techniques available to threads but, once again, what
is the application doing? Do you have a test application in mind? Someone
willing to code the Threads version? I'll happily provide the AST version!
Anyway, if you've now come to the only sensible conclusion available, you're
about to embark on the quest to develop an AST threaded server. Good start!
Couple of landmines in the way :-(
a) Do I have to code to monitor the status of all these network connections?
Every time? Every Application?
b) How do you restrict access to my server application to only authorized
clients? Furthermore, how can I establish what rights and privileges each
client is entitled to on the server node?
c) How do I provide the multi-threading capability needed to allow my server
application to deal with multiple client requests simultaneously?
d) Is there a way to prevent data corruption by encompassing all of the
modifications to my distributed data sources under the ACID-umbrella of a
true Two-Phase Commit?
But all you wanted to do is write a student enrolment system :-( Why are you
having to worry about all this? Are you going to have to repeat this process
all over again when you want to develop a queue manager system, or a library
application?
A wise man once wrote: -
"I have usually found it more economical to use existing middleware than to
write it fresh "
With that in mind I'm going to send you (under seperate cover) an evaluation
copy of Tier3 V3.1 and the "TIER3 Client/Server Development Manual". You
don't have to read the manual and test the software, but I can guarantee
that, if you do, your time will not be wasted.
Cheers Richard Maher
"JF Mezei" <jfmezei.spamnot@xxxxxxxxxxxx> wrote in message
news:445AA9ED.AF58E262@xxxxxxxxxxxxxxx
Bob Gezelter wrote:
The beauty of AST based applications is that the implicit lock (which
is really access to the process stack) is limited to one at a time.
My point was that a single threaded AST based application maje be able
to take care of multiple clients at the same time, but it will not be
splitting processing between CPUs. I was asking about the possibility of
declaring an application capable of having multiple AST queues that can
execute on multile CPUs concrrrently. (and obviously coding so that
this is safe).
It wouldn't be a multi-threaded application. But by being able to use
multiple AST "processors", its throughput would be much greater.
Having a single threaded AST-based server process on a 128 CPU machine
won't be able to make use of 128 CPUs and will use only one. Right ?
The ability to tell the OS that your application was written so that
ASTs can be delivered concurrently on different CPUs would allow one to
make full use of the multi-CPU system.
.
- References:
- Miltu-core CPUs, threads vs AST driven approaches
- From: JF Mezei
- Re: Miltu-core CPUs, threads vs AST driven approaches
- From: Bob Gezelter
- Re: Miltu-core CPUs, threads vs AST driven approaches
- From: JF Mezei
- Miltu-core CPUs, threads vs AST driven approaches
- Prev by Date: Re: Mac OS X no longer immune to viruses!
- Next by Date: Re: Mac OS X no longer immune to viruses!
- Previous by thread: Re: Miltu-core CPUs, threads vs AST driven approaches
- Next by thread: Dumb C programming question; where to put character constants
- Index(es):
Relevant Pages
|
Loading
