Re: Miltu-core CPUs, threads vs AST driven approaches

JF Mezei wrote:
Say you are writing some internet server that can accept multiple
simultaneous connections.

One can write an AST driven application where the parameter given to the
AST points to a control block that fully describes the connection
context for that remote user. Or, you could go the multi threaded way
where each thread acts independantly and waits for input (while other
threads may be busy).

On a single CPU, there wouldn't be much difference, unless the
processing for each transaction takes long time.

Incorrect, unless each such transaction performs no disk (or similar) I/O.

For AST driven, nothing
happens until one transaction completes and the next AST kicks in.

Incorrect if the transactions perform disk I/O (or any other lengthy operation where the CPU can be freed up to do other work). If correctly written, the current transaction will issue the I/O (or similar - waiting for a lock might also qualify) request asynchronously, exit the AST (the operation completion being what wakes up the transaction again to continue), and make the single CPU available to service any other pending AST for another transaction.

For
thread driven the pre-emptive multitasking can suspend one thread and
give some CPU to another thread.

Probably not what will actually happen, unless the transactions perform no disk (or similar) I/O. Instead, the issuance of the I/O by a thread will cause the CPU to suspend it (not preempt it) while the I/O executes, making the CPU available to any other waiting thread.


Now, when it comes to multi-core CPUs, is it fair to say that the multi
threaded approach will win hands down because it will be able to make
full use of the multiple cores whereas the AST will all be serialised on
one CPU ?

Only to a point - specifically, the point at which the number of threads equals the number of available CPUs. Beyond that point, using ASTs in each of those threads will likely perform better (not only would additional threads consume additional resources - e.g., virtual memory - but having more threads than processors opens up the possibility that the threads will compete for individual processors and hence incur preemption and things like otherwise unnecessary lock-contention overheads that ASTs do not - the same reason why the AST-driven approach may be superior for single-processor systems, incidentally).

Assuming, that is, that Bob's comment about the ability to execute ASTs concurrently for different threads in a multi-CPU process is correct (i.e., that inter-thread behavior resembles inter-process behavior in this regard; otherwise, you might be better off with a process per CPU and some shared memory to use for inter-process coordination, but that would be noticeably messier).

- bill
.

Relevant Pages

  • Miltu-core CPUs, threads vs AST driven approaches
    ... Say you are writing some internet server that can accept multiple ... simultaneous connections. ... One can write an AST driven application where the parameter given to the ... On a single CPU, there wouldn't be much difference, unless the ...
    (comp.os.vms)
  • Re: Miltu-core CPUs, threads vs AST driven approaches
    ... But my suggestion still stands. ... AST is a great dispatcher for tasks. ... delivered on any CPU. ... Because the AST scheduler does not make use of multiple CPUs for the ...
    (comp.os.vms)
  • Re: Concurrent Sequential
    ... Part B could be "starved" of the CPU. ... interrupt" it seems inflexible. ... OK, lets look at a simplified transaction system. ... There are usually dozens of transactions "in process" at any one time; most of them are waiting for an I/O completion. ...
    (comp.arch)
  • Re: AST level I/O
    ... :I am wondering about I/O to SYS$OUTPUT from nonAST code which might be ... :I/O, is interrupted, then the AST thread goes and issues an I/O the ... :I can block ASTs in the synchronous thread or is I need to write to ... The AST drops work packets onto a queue processed by the mainline, ...
    (comp.os.vms)
  • Re: Gartner report on VMS future.
    ... how we did async programming ... an AST is nothing more nor less than an interrupt. ... things like announcing I/O completion. ... An AST is an interrupt, delivered at a priority of ASTDEL. ...
    (comp.os.vms)