Re: [open-cobol-list] writing concurrent code : possible with gnucobol?

[Brian Tiffin]

Mayuresh Kathe wrote:
> hi,
>
> do cobol in general and gnucobol specifically possess any capabilities
> that can facilitate writing programs which can take advantage of
> today's multi-core hardware systems?
>
> suppose i wish to write a financial accounting system running atop a
> gnu/linux based distribution like say ubuntu, would gnucobol run as a
> single threaded process? or can i introduce concurrency? and is it easy
> to achieve?
>
> if yes, any pointers for reading material would be nice to have. :)
>
> thanks,
>
> ~mayuresh
Possible, but with care.  The more critical the application, the more 
care that needs to be shown.

When I coded up the libmicrohttpd example, I first just had it display 
some simple HTML, it worked, and I thought I was finished. Upon 
revisiting, some year and a half later, to make the sample look a little 
nicer, I added a CSS link inside the HTML.  libmicrohttpd exploded into 
chaos, it had spawned a thread internally to load the CSS while the HTML 
object was loading.  That causes the working-storage section of the 
callback handler to be shared, and the chaos ensued.  A quick fix was 
moving critical data to a local-storage section, so the pointers and 
buffers used end up per thread and not just per process.

Mutex locks would also be required for any purposely shared data. So, 
yes it's possible to thread GnuCOBOL, but it does not come "for free", 
design issues must be approached with care, and control flow, controlled.

Bing google for "gnucobol libmicrohttpd" to find the thread.  That 
discussion thread does not explicitly use threads, libmicrohttpd did 
that in the background, but it should not take much to create a test 
head using pthread_create and setting the start_routine as a 
PROGRAM-POINTER loaded with SET pp TO ENTRY "subprogram".   During a 
CALL to phread_create the pp would then be passed BY VALUE, not by 
reference, as C will want the actual address, not the address of the 
COBOL pointer.  Some, (most?, all?) the data inside the subprogram would 
need to be in local-storage or explicitly accessed through mutex 
routines.  Depending on the sharing, even the data in local-storage 
might need said lock steps.

We can talk more Mayuresh, if you end up needing more help.  It might 
give me an excuse to write up another entry for the FAQ.

And, although it doesn't really answer the question in any concrete way, 
Dr. Richard Hipp is not a fan of threads, and points to a UBerkeley 
article in the SQLite FAQ, Threads are Evil, Avoid them. 
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf The 
fossil SCM is coded to work without threads, except in Windows where 
they could not get http servers to work without them.

For mission critical applications, either great care must be shown, or 
alternative concurrency models should be sought.  I'd be more than 
willing to help in that area, as GnuCOBOL deserves to be considered best 
of breed reliable if applied to concurrent financial scenarios.  But, 
that is a heady area of computer science, a tad above my pay grade most 
days, but I'd be willing to help write tests for any models put in place.

http://fossil-scm.org/xfer/doc/trunk/www/style.wiki
https://www.sqlite.org/faq.html#q6

I'm a huge fan of Dr. Hipp, and I believe his views to be the correct views.

Cheers,
Brian