- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- About migrating application to POSIX THREADS
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-08-2008 01:15 AM
02-08-2008 01:15 AM
Re: About migrating application to POSIX THREADS
http://wasd.vsm.com.au/ht_root/src/httpd/readmore.txt
It's the Nuts and Bolts document describing the WASD HTTP Server. It is a highly concurrent, multi-threaded (with AST's, not a threading library) HTTP server.
The WASD VMS Hypertext Services - Technical Overview http://wasd.vsm.com.au/ht_root/doc/htd/ has a chapter on performance (21). This is the first paragraph
"The server has a single-process, multi-threaded, asynchronous I/O design. On a single-processor system this is the most efficient approach. On a multi-processor system it is limited by the single process context (with scripts executing within their own context). For I/O constrained processing (the most common in general Web environments) the AST-driven approach is quite efficient."
I think it would be worth your time to look at that before you decide to rewrite using pthreads.
Good Luck,
Jon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-08-2008 03:11 AM
02-08-2008 03:11 AM
Re: About migrating application to POSIX THREADS
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-08-2008 04:19 AM
02-08-2008 04:19 AM
Re: About migrating application to POSIX THREADS
Indeed. When I speak and teach about implementing concurrency, I always speak about a "pyramid of complexity". Ascending each step of the pyramid requires a positive statement. For example:
- Going from simple sequential code to event driven code requires that the sequence of events be indeterminate (e.g., timeouts and network connections, or multiple network connections). A simple payroll computation program would never present that condition.
- Going from non-preemptable threading (e.g., AST, the equivalent in POSIX threads) requires that the processing of each event exceed the computational capacity of a single CPU OR introduces unacceptably long latencies.
In thirty years of working with event driven code and threads, I can only count a relative handful of cases that met the second criteria needed to go to pre-emptable threads. In most cases where pre-emptable threads were perceived to be "the solution", the true underlying problem was some form of synchronous processing that became [unnecessarily] embedded in the event processing.
WASD is a good example of how high performance is quite achievable.
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-12-2008 01:23 AM
02-12-2008 01:23 AM
Re: About migrating application to POSIX THREADS
Thanks for everybody and i´ll tell you my advances.....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-12-2008 04:22 AM
02-12-2008 04:22 AM
Re: About migrating application to POSIX THREADS
Well Duh! No kidding huh? !?
You would have the same (file) locking as with 1 process. I fact it may well be worse as RMS now may have to 'ping' the most recent block from one process to the next and back aided byt the XFC (after writing to the disk)
>> afraid i have the bottleneck with the application files.
Well Duh!
That would be true for 95% of all your applications. If if was not true the application you work on, then you would have known this and would have been able to 'proof' it with argumentation.
>> And the cost of sinchronizing is high.
Duh!
I see stuff like applications taking out a lock, reading a record which holds a next value, update, write new record using that next new value, release the lock. All they needed to do was to just keep the next-new-key value in the lock value block, update teh underlyng storage ever 10 minutes or 100 updates, and release the lock for the next user.
Good luck!
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-12-2008 06:31 AM
02-12-2008 06:31 AM
Re: About migrating application to POSIX THREADS
Designing for performance can be subtle. Your most recent posting included the comment:
"... Because i need to sinchronizing the concurrent access at one of the application file, i use a lock for this operation. ..."
This may be a mis-communication, but if a single lock is being used to control access to the file as a whole, that would be an unneeded bottleneck. RMS shared writing does things far more efficiently than that, as can a directly implemented non-RMS scheme.
If this is the problem, a correction would be far more less work than restructuring to a different approach (and the different approach may very well not yield the benefits desired).
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-12-2008 07:16 AM
02-12-2008 07:16 AM
Re: About migrating application to POSIX THREADS
Build and invoke with the DECset tool Performance and Coverage Analyzer (PCA) within this application as currently designed, and find out where the code is (really) spending its time. Be prepared for surprises.
On newer OpenVMS versions, you can use some of the built-in PC profiling tools (SDA Extensions), but DECset PCA does a better and more complete job.
- « Previous
- Next »