Pandyan wrote:Even a basic/innocuous webserver/webservice does that. programmer writes a single threaded code and IIS/Apache let's you scale by parallelizing the work and lets you scale based on demand
Exactly. That is why I wrote that bit about WebServer /App Server having that kind of functionality built in. With frameworks such as Swing and stuff like EJB, no DOO is going to do anything on the server side with threading and rubbish. It will be just a single threaded changu-mangu program which gets deployed with all that functionality. Thank goodness for that.
Pandyan wrote:Mickey/Chipzilla Thread building blocks etc provides automatic thread management capability.
So, there are several tools in developers tool chest now to do what you are asking for without breaking the bank.
Yes, stuff like Boost libraries etc are a good step, but why go that route at all, and let DOOs muck things up. That is the question. Take it away from them.
Saik wrote:also, there is tremendous capabilities lies in non-blocking i/os.. os controlled, one could do 1000s of process using this approach. ideally done by containers of services and process/threads that needs to wait, and free up cpu for other works.
EXACTLY. The way, that all those webservers and "internet architecture" scales up to multi million transactions with fast response is fundamentally the same as CICS and other TP monitors. They use what is called as
Pseudo Conversational Transaction. Remember, HTTP too is a stateless protocol and the context is lost between conversations. Say between clicking on stuff and putting it on a shopping cart and finally clicking buy, the context is lost . The context is actually stored on the server side and retrieved via the cookie ? ,info that travels between the browser and Web/App Server.
The same thing is done in CICS. The difference is that in the "container and services" world (that I have seen until now), the server side thread is still alive (albeit in sleep/wait , along with locks to database etc), while in CICS, everything is released, which leads to even higher throughput. So, really internet transactions is basically CICS kind of model implemented in a browser & server mode (you do have client server version of CICS as well). So welcome back to 1975 ji!
Anujan wrote:
1) Writing thread safe code is a pain. Writing reentrant code is a pain in the mushrraf.
2) Partition level memory protection instead of thread level protection.
3)Are you sure that systems of old were really that awesome? I mean the reason I find it hard to believe is because CS has made significant advances in memory consistency models, address space protection, and programming models that hide things like requirement to write renetrant code -- all in the past decade and a half. Or is it just a case of "In my time, we walked 10 miles uphill to go to school and another 10 miles uphill to come back home"
1) Fundamentally all the code one writes is re-entrant, which basically means that the code segment is invariant. What used to be the case is that some Cobol versions of the 60s, allowed the code segment to be changed via instructions. That is a non issue. All shops would have upgraded their compilers when they got CICS and the default settings would compile fully re-entrant code only. So this really is a non issue.
To screw things up, you need to go back, write some really malicious code and change compiler settings to compile it to 60s style stuff (which most shops wont allow you to do, and if at all, they do , it usually will be for any program from 60s backward compatability, only allow you to run it not in CICS, but under MVS) and somehow get the CICS admin to authorize you to load that.
Other than that, effort and anything wise, you don' need anything beyond writing a changu-mangu "Hello World" program, because, by default , a "Hello World" program is fully re-entrant (in any language and platform usually).
2) But remember, each of the thread doesn't have mutexes and pointer arithmetic and no memory handling (like using malloc() ) , so, it is quite okay to have memory protection at that level, instead of thread level. That said, CICS is no as bullet proof as DB2 under MVS (a fully tasked system , unlike Oracle and others which do threading, it is unheard of DB2 to crash, while Oracle and others do crash) and does crash on extremely rare occasions.
3) Refer back to 1). Writing re-entrant code is not an issue. Your normal changu mangu code is re-entrant (without all that mutexes and threads and dynamic memory allocation etc ) . In fact, it is quite easy. Just write straight logic and leave the rest of that stuff to the system , so programming wise it is in fact easier . The thing is ,that tools wise, the SDKs in other platforms were streets ahead of what you got for CICS and old IBM systems , that automated a lot of stuff and improved productivity.