Understanding Process Games in Systems Programming Lab
Explore the simulation of process games where programs replicate themselves within a limited arena, learning about the players' goals, finding processes through /proc, and the purpose of the pseudo-file system. Discover the significance of /proc in accessing process information and the methods to interact with it.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
CS252: Systems Programming Ninghui Li Topic 18: Lab 6: The Process Games
The Process Games In each process game, between 2 and 5 programs can participate. The arena program creates (i.e., forks) N processes of each program, where N is at least 10, and N*P is at most 100. Each program is loaded with N and P given as arguments. The total number of processes in the arena is limited to N*P once the arena starts.
The Players The goal of a participating program is to make as many processes in the arena to be duplicates of itself. A player must thus Find target Use /proc, guess PID, etc. Kill target (kill) Duplicate itself (fork)
Finding Other Processes via /proc What is /proc? A pseudo-filesystem that acts as an interface to internal data structures in the kernel What is it used for? Can be used to obtain information about the system Can be used to change certain kernel parameters at runtime.
Why the Pseudo-File System Create pseudo-filesystem to represent status information and configuration parameters as files Provides a unified API for collecting status information and configuring drivers Control access through UNIX permissions No new libraries needed simple filesystem calls are all that is necessary Quick, easy access via command line Not version- or configuration-specific
Process Information Each process has a /proc directory identified by its PID - /proc/PID/ Symlink /proc/self/ points to the process reading the file system Allows access to Process status Process memory information Links to cwd, exe, root dir Pending signals Many other information
Accessing /proc Use standard filesystem API Including openat/getdents/opendir/readdir/readlink/read Use /proc specific api I.e., openproc/readproc/readproctab See, e.g., source code of pkill/pgrep at https://github.com/soarpenguin/procps- 3.0.5/blob/master/pgrep.c
Friend or Foe? Possible strategies Check whether /prof/pid/exe matches argv[0] Use IPC between friends E.g, use shared memory as a bulletin board shared by all friends E.g., use signals Possibly others Don t care .
How to Coordinate? Global coordination (E.g., shared memory) Local coordination Each process makes decision based on local information No coordination
Strategic Thinking Fast and furious versus methodical Is the overhead worthwhile? Should one use different strategies based on values of N, P? Should one have different instances of the players adopt different strategies?
Other Things to Explore Understand what existing players do? Use strace to find out the system calls made by a player, and experiment to understand relative performances The result may be surprising, Understand process scheduling and system calls made Possibly use auditctl
Grading Base score = Avg score over applicable testing scenarios In each scenario, Avg of middle 3 performances, each measured as the percentage of remaining processes after 10 seconds, 1. vs. fork (N=10, 20, 30, 40, 50) 2. vs. digger (N=10, 20, 30, 40, 50) 3. vs. sniper (N=10, 20, 30, 40, 50) 4. vs. phalanx (N=10, 20, 30, 40, 50) 5. vs. hitman (N=10, 20, 30, 40, 50)
Grading (Continued) 6. vs. digger + sniper 7. vs. phalanx + sniper (N=10, 15, 20, 25, 30) 8. vs. hitman + phalanx (N=10, 15, 20, 25, 30) (N=10, 15, 20, 25, 30) Team of 4 (all 8 scenarios) Team of 3 (scenarios 1-7) Team of 2 (scenarios 1-6) Team of 1 (scenarios 1-5)
Grading: Extra Credit 10% extra for winning against flash (N=10, 20, 30, 40, 50) Top 8 joins a tournament, receiving 10%, 8%, 6%,5%,4%,3%,2%,1% extra credit
How to Set UP? Install Oracle Virtual Box Download the VM image Log in as cs252 Commands cd lab6, su arena1 or arena2 ./arena 20 ./fork ./prog sudo bash top u arena1 pgrep lu arena1 prog pkill KILL u arena1 show remaining processes
Submit Use turnin to submit
Clicker Question 1 (signals) Which signal is sent when the Child process terminates? A. SIGINIT B. SIGCHLD C. SIGKILL D. SIGSTOP E. None of the above
Clicker Question 2 (Signals) Which of the following signal cannot be handled or ignored? A. SIGINT B. SIGCHLD C. SIGKILL D. SIGALRM E. None of the above
Clicker Question 3 (Signals) Which system call(s) cause the sending of a signal? A. kill B. signal C. sigaction D. Both A and B E. Both B and C
Clicker Question 4 (Signals) What is the output of the code below? A. Error child cannot send a SIGKILL signal to parent. B. Parent goes to the signal handler, prints handled signal and goes back to sleep C. Parent goes to the signal handler, prints handled signal and exits D. Parent sleeps for 20 seconds, without going to signal handler E. Parent exits without going to the signal handler void handler ( int signum) { printf( Handled signal\n ) } int main() { int pid; signal (SIGKILL, handler); pid = fork(); if (pid==0) { kill(getppid(), SIGKILL); exit(0); } else { sleep(20); } return 0; }
Lab 6 as a Small Research Project When you start, you don t know what the result is going to be. Need to try things and see if they work. The solution depends on assumptions. The solution may be simple. May need to spend more time thinking than coding. There is always a bit of luck involved.
Lab 6 Initial Experiments Blind kill & fork Often cleans up arena Find target pid, check if its is friend, then kill Quite slow if needs to access /proc Get a list of process information in one system call, then kills off one by one. Still lots of system calls Coordinate using shared memory. Slows down the beginning
Thinking Process What happen when loading the program A lot happen in exec(), shared library needs to be loaded. if you need to read /proc or use shared memory, shared memory libraries need to be loaded What about using static linking? How big is the binary file size of a program doing less than hello world, when statically linked? Decisions are reached within the first second or so. What factor in the program matters the most?
What Condition Should an Optimal Strategy Satisfy? So long as one instance of the program runs, it wins. That is: a strategy is optimal if it kills off all enemy processes in the first time slice Can we do that? Yes, with a simple program, and killing without forking.
Implementation of an Optimal Strategy: Just Kill while ((cpid = fork()) < 0); int main(){ if (cpid == 0) { int i, j, n = 0; while (1) { pid_t pid,cpid,upid,lpid; fork(); cpid = getpid(); } upid=cpid; lpid = cpid; } for (i=0; i<500; i++) { /* first instance kills off every other process, populates the arena by forking, and then bows out, solving zombie problems. upid = upid+1; if (upid > MAX_PID) upid = 400; kill(upid, SIGKILL); */ lpid = lpid-1; } kill(lpid, SIGKILL) ; }
Next Time This Project Make pids of new processes random Or keep an arena process, and forbid killing it.
