Operating system structures:
Process control block:
struct task_struct
PCB does not
store all the complete struct rusage
data.
What are at least two reasons it does not?
Four processes are ready to run. Their CPU burst times are 2, 4, 2 and 6.
Consider the following SOS semaphore implementation
of a wait call (additions to system.h
shown on top):
/*--------------------------------------*/ /* extra system.h stuff */ #define NUM_SEMS 50 /* semaphore data structures */ struct semaphore { int allocated; int count; int use_count; int id; pid_queue queue; }; struct semaphore sema[NUM_SEMS]; /*--------------------------------------*/ /** signal **/ void SignalSemaphore(int sid) { sema[sid].count++; if (sema[sid].count <= 0) pid = remove(sema[sid].queue); pd[pid].state = READY; } return; }
Write the corresponding wait code for the below prototype:
void WaitSemaphore(int sid);
For the SignalSemaphore code in previous problem, where might there be a race condition in the OS itself? What solutions might the OS use to avoid any race conditions in SignalSemaphore? Be specific.
Consider running the following psuedo-code on a Unix system:
/* global variable */ int n=0 main() { fork() n = n + 1 printf("%d ", n) }
Assume all system calls succeed.
n
is changed to a variable in shared
memory among all processes and the code is re-compiled and ran.
Now,what are the possible outputs?
Consider the test_and_set solution for a race condition we discussed in class:
int lock /* shared */ while (1) { while (test_and_set(lock)) /* no op */ ; /* critical region */ lock = false /* remainder */ }
Using the SOS process control block (struct
ProcessDescriptor
) as declared in system.h
as a template,
provide a struct ThreadDescriptor
that contains exactly
enough information to save and restore threads and provide a way to
reference the containing process.
Provide two programming examples of multithreading that do NOT improve performance over a single thread solution.
Return to the CS3013 Home Page
Send all questions to the TA mailing list.