Arlon's CSUMB Intro to Operating Systems CST-334 Module 2 Learning Journal #2/#26 for the week Wed 06/30-Tues 07/06, year 2021

Arlon's CSUMB Intro to Operating Systems CST-334 Module 2 Learning Journal #2/#26 for the week Wed 06/30-Tues 07/06, year 2021

This week in class we studied switching processes/threads and creating threads in C, and the theory aspects of how the kernel decides prioritization of threads with regard to when and how long they should be allowed to run, various partial strategies including round robin, FIFO, SJF, ending with multi-level feeback queue. We also started using makefiles for C programs.

In threads study lab this week on top of testing variations of running child and parent threads I also found a way to turn a conditional inside-out with anonymous functions and a conditional operator, something like:

/* Name: Arlon Arriola  Date: 07/06/2021
  Title: Lab2–threads/processes/child/parent–Alternative conditional structure
  Description: Study of alternative conditional structure for Lab 2–threads/processes/child/parent
*/
#include <stdio.h>/* printf, stderr */
#include <sys/types.h>/* pid_t */
#include <unistd.h>/* fork */
#include <stdlib.h>/* atoi */
#include <errno.h>/* errno */
#include<sys/wait.h>/* wait */
int main(int argc, char * argv[]) {
  pid_t  pid;
  int i, n = atoi(argv[1]); // n microseconds to input from keyboard for delay
  printf("\n Before forking.\n");
  pid = fork();
  if(pid == -1)return fprintf(stderr, "can’t fork, error %d\n", errno);
  return printf("%s Process - pid: %d  - instance: %d.\n",({ char * parent_or_child (int pid) { //  Anonymous method for parent or child
    return pid?     //  A conditional operator inside a printf - instead of printf’s inside a conditional! (there’s still print’s in there,
      ({ char * parent (int pid) { //  Anonymous method for parent    //   in the interior, but this shows how you could pull them out -
        for(i=0;i<100;i++){printf("Parent Process pid: %d \n",pid);usleep(n);} //   the outter printf is doing the same thing - optionally
        // More parent stuff could go here                                      //  loop it, return later, etc.)
        return "Parent";
      }  parent; })(pid)
      :
      ({ char * child (int pid, int i) { //  Anonymous method for child
        for(i=0;i<100;i++){printf("Child Process - instance: %d. pid: %d. Sleep Time: %d usecs.\n" ,i ,pid ,n);usleep(n);}
        // More child stuff could go here
        return "Child";
      }  child; })(pid, i)
    ;
  }  parent_or_child; })(pid), pid, i);
}

for interesting variation with anonymous functions and a conditional operator. The advantages being that a) it’s interesting syntax with anonymous functions (I think - they’re labelled - I think they’re still anonymous though) and b) you could use this design to bring the printf output out of the interior of the structure. Interestingly, trying this idea led me to discover a large difference in where the call(s) to usleep(n); is/are. If I put one after printf, there is less alternation between parent/child (at least on my system, Linux Mint, medium-to-old-computer, 16gb ram, 3.somethin’ ghz proc.) than if I put it inside or before it, and the most alternation if I put them inside the inner loops. I think this is because the printf is output to the screen, and this has to do with when it sleeps with relation to how long output takes.

To figure out if I was on to something last week, or treading in dangerous waters I bought the book "Understanding and using C pointers" and some other books on C, read the section on 'Function Pointers' thoroughly, found it to be a thorough section - except - that they didn't show how you could create a gigantic hierarchically organized logical program with function pointers and nested structures like I did last week [link to my journal #25 from last week]

And upon further reading, I don't see anywhere where this type of paradigm could cause any type of problem except perhaps lack of optimization for what is known as branch prediction - processor lookahead of potential processor outcomes - but a) I don't care for now and b) I could test once I learn how and see, if it does cause any slow down. For now I will say that is a really good way at least for myself to build a really huge program with tons of included features and functionality all built in a logical progression.

So hopefully I discovered a good paradigm, if not at least it helped me discover anonymous functions for discussion in this weeks journal post on threads! Neato! Studying threads is very interesting! I like testing all the different ways it can run, depending on where you put usleep(n);and what you set n, the wait time to be, and experimenting with fork().