- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Moving a multithreaded project from IVF9.1 to 11.0.074. In v9 each routine which needed it was independently specified as RECURSIVE, worked perfectly for threading. IVF11 now requires the /recursive compiler option, but setting /recursive also implements AUTOMATIC, which seems to override /Qsave, and so lots of things which used to work now require chasing down and adding individual SAVE attributes. (/Qsave is invoked to emulate CVF and other older compilers.) I can't see why this is an improvement.
I have also explored the /reentrancy: threaded option, and am curious about the interaction between this and /recursive. Our code seems to work just fine with /recursive alone. Adding /reentrancy: threaded pumps up the size of the executable by about 300Kb, but otherwise has no obvious effects on runtime performance. Are these two linked? Can/should one be invoked without the other?
TIA
I have also explored the /reentrancy: threaded option, and am curious about the interaction between this and /recursive. Our code seems to work just fine with /recursive alone. Adding /reentrancy: threaded pumps up the size of the executable by about 300Kb, but otherwise has no obvious effects on runtime performance. Are these two linked? Can/should one be invoked without the other?
TIA
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't understand your comment that "IVF11 now requires the /recursive compiler option". Please elaborate.
If you are using /Qsave, it has no effect on RECURSIVE routines.
/recursive is the same as /auto - it causes the default local storage for routines to be stack-based. /reentrancy:threaded is a direction to the run-time library as to whether or not it should protect its internal data structures against reentrancy. It causes a call to for_set_reentrancy to be added at the beginning of the main program. This also (I think) causes the thread-safe libraries to be linked in, hence the extra code size.
If you are using /Qsave, it has no effect on RECURSIVE routines.
/recursive is the same as /auto - it causes the default local storage for routines to be stack-based. /reentrancy:threaded is a direction to the run-time library as to whether or not it should protect its internal data structures against reentrancy. It causes a call to for_set_reentrancy to be added at the beginning of the main program. This also (I think) causes the thread-safe libraries to be linked in, hence the extra code size.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1. RECURSIVE routines in v11 hang unless /recursive is specified -- ie, thread routines don't work etc.
2. The /auto aspect of /recursive seems to take precedence over /Qsave -- former behavior achieved via /Qsave now must be implemented with specific SAVE attributes on each variable. Making the expected behavior explicit in code is probably good practice, but, again, this is very different from the IVF9.1 behavior.
3. Have not yet had any problems due to omitting the /reentrency: threaded option. Is this required or merely some degree of advisable?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Example of problem, please. None of these are issues I am familiar with.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page