4

i'm studying for a test is OS (unix is our model). i have the following question:

which of the following 2 does NOT cause the user's program to stop and to switch to OS code?

A. the program found an error and is printing it to the screen.

B. the program allocated memory that will be read later on from the disk.

well, i have answers, however, i'm not sure how good they are. they say the answer is B. but, B is when the user uses malloc which is a system call no? allocating memory doesn't go through the OS? and why printing to the screen should need the OS for it?

thanks for your help

Tim
  • 834
  • 2
  • 12
  • 31
Asher Saban
  • 4,673
  • 13
  • 47
  • 60

4 Answers4

5

malloc is not a system call. It's just a function.

When you call malloc it checks to see if it (internally) has enough memory to give you. If it does, it just returns the address - no need to trap into kernel mode. IF it doesn't have it, it asks the operating system (indeed a system call).

Depending on the way printing is done, that too might or might not elicit a system call. For instance if you use stdio, then printing is user-buffered. What that means is that a printf means copying to some stdio buffer without any actual I/O. However, if printf decides to flush, then indeed a system call must be performed.

cnicutar
  • 178,505
  • 25
  • 365
  • 392
1

graph showing layers: program, libc, kernel

printf() and malloc() calls invoke the C runtime library (libc). The C runtime library is a layer on top of the kernel, and may end up calling the kernel depending on circumstances.

The kernel provides somewhat primitive memory allocation via brk() (extend/shrink the data segment), and mmap() (map pages of memory into the process virtual address space). Libc's malloc() internally manages memory it has obtained from the kernel, and tries to minimize system calls (among other things, it also tries to avoid excessive fragmentation, and tries to have good performance on multi-threaded programs, so has to make some compromises).

stdio input/ouput (via *printf()/*scanf()) is buffered, and ends up calling the kernel's write()/read() system calls. By default, stderr (the error stream) is unbuffered or line-buffered (ISO C §7.19.3 ¶7), so that errors can be seen immediately. stdin and stdout are line-buffered or unbuffered unless it can be determined they aren't attached to an interactive device, so that interactive prompts for input work correctly. stdin and stdout can be fully-buffered (block-buffered) if they refer to a disk file, or other non-interactive stream.

That means that error output is by default guaranteed to be seen as soon as you output a '\n'(newline) character (unless you use setbuf()/setvbuf()). Normal output additionally requires to be connected to a terminal or other interactive device to provide that guarantee.

ninjalj
  • 42,493
  • 9
  • 106
  • 148
0

The answer is A. Handling an error after it is detected is handled by the programming language run time and user space application. On the other hand, mmap'ing a file requires entering kernel mode to allocate the necesary pages and queue up any disk IO. So B is definitely not the correct option.

Mikola
  • 9,176
  • 2
  • 34
  • 41
0

In A the user program is responsible for detecting the error and deciding how to provide that information. However in most cases actually rendering characters to a display device or terminal will involve an OS call at some point.

In B the OS is certainly responsible for memory management, and allocation may at some point request memory from the OS or the OS may have to provide disk swapping.

So the answer is probably strictly neither. But A will require a system call, whereas B may require a system call.

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • @cnicutar: `stderr` is unbuffered/line-buffered by default. – ninjalj Jun 25 '11 at 08:27
  • @ninjalj The op didn't mention `stderr` in the original question; default != always. So the "*will*" is "*might*". – cnicutar Jun 25 '11 at 08:29
  • @ninjalj I am assuming nothing and explaining all the implications. – cnicutar Jun 25 '11 at 08:31
  • @cnicutar; I fail to see your point; if no flushing is done, nothing is displayed, and the the question explicitly says "printing to the screen", so one as to assume that action is taken to cause that to happen. – Clifford Jun 25 '11 at 19:24
  • @Clifford Why assume anything ? He didn't say "the message is displayed" or "the photons from the message are hitting my retina". The question said: "printing". Okay, `printf("Danger!"); _exit(1);`. How many syscalls will that printf bring up ? – cnicutar Jun 25 '11 at 19:28
  • @cnicutar: Well how would yo interpret *"printing it to the screen"*!? I don't think I made any assumption there; just read the question! If the requirement is to display it to the screen, then the program must take the necessary action to ensure it is rendered visible; otherwise it is not displayed, and the requirement not met. – Clifford Jun 27 '11 at 19:40