2

I have been thinking. Let's consider this example: We have 2 programs running on PC. First is, for example internet browser, and second is some WiFi scanning software. Now, browser wants to use internet connection over WiFi, but WiFi scanner need the WiFi adapter to be switched into scan mode...

OK, so, which side in a modern OS architecture is responsible for handling these kinds of collisions? Some OS layer, device driver, or the program itself?

Because, for example the WiFi scanner scanner switched the WiFi adapter into scan mode. Now, the browser has been launched. So the OS switches CPU time to the browser. It calls some abstract OS layer for network which calls the WiFi driver and wants to receive data from it.

Basically, I want to know, how are these situations solved. I have been tinking about it a lot, but I never actually figured it out. Becouse, there are several options:

For example, OS built-in API functions, like for example basic API for printing text to console, or drawing to Windows handles which process to which actual frame on screen itself, and calls the GPU driver itself, so no collision there.

But, you can write your own drivers, not lying under some heavy OS API. And then 2 applications can use this driver for two opposite functions. My main problem in understanding this is the multitasking environment. Because how can process 2 call some driver function if process 1 called it before, and it got switched to process 2 before driver request was completed? Thanks.

slhck
  • 235,242
Vit
  • 23

1 Answers1

3

Answer to you specific question (browser with scanner). In each OS I know, if WiFi card gets switched to another mode, other application will just lose connectivity (in case when they cannot switch that mode back, but it's unlikely for a browser). Connectivity returns when scan's finished.

And more abstract answer. In each sane operating system there's a HAL - Hardware Abstration Layer. Even X Server nor Windows' windowing system doesn't call video/mouse/keyboard driver directly. Every request has to go through HAL (so, for example, a filesystem doesn't need to know if specific device is a pendrive, hard drive, or something else, it's just a block device).

I'm pretty sure that HAL maintains some kind of queue of requests which have to be passed to specific driver. So, basically, only problems caused by multithreading are race conditions, as this queue is FIFO (First In First Out). So, in a situation with a scanner and browser, if scanner is first application/thread to access WiFi card, it wins and regular connectivity is lost. But, if a browser would make it's request first, then it would be able to receive data, and mode would be switched a bit later.

I hope this clears things up.

Dr McKay
  • 288