How does kernel handle simultaneous i/o requests ?

[sanjeevmk]

Hi,
I have the following program design in mind for an application to be developed on the linux kernel:

The program will have multiple threads, using pthreads. The threads could be running on the same or different cores (cpus). I am developing it for a hexacore system and will use the pthread library routines to set cpu affinities of the threads. So, there will be multiple threads running in parallel on different cores at any instant of time. Also, each core could have more than one threads running on it.

Each of the threads might need to interact with external hardware through i/o ports.So, there are chances that two threads might access i/o at the same time.
I need some guidance regarding how the Linux kernel handles such simultaneous i/o requests.

Specifically, I want to know the thread-blocking decisions of the kernel , for the following cases:
1. Two threads on same core access the same i/o port.
2. Two threads on same core access different i/o ports.

3. Two threads on different cores simultaneously access the same i/o port.
4. Two threads on different cores simultaneously access different i/o ports.

Thank You,
Sanjeev.

[NickJohnson]

Simple: the driver using those I/O ports doesn't access them with multiple threads at the same time (using some sort of locking mechanism, usually.) I.e. nobody actually "solves" this problem, because any general "solution" would end up being equivalent to more complicated locking.

[bewing]

And your cases 1 and 2 aren't really sensible. A single core can only do one thing at a time. It can only run one thread at a time (in reality) and can only access one IO port at a time. It only looks like two threads are running simultaneously because it switches back and forth faster than your eye can see.

As NickJohnson said, for case 3 you either use any form of locking, or you use protection mechanisms in your Device Manager to make sure that only one thread (driver) ever owns a particular IO port for a particular hardware device (and therefore does not need locking).

Case 4 is not an issue. As many cores as you like can access as many different IO ports as you like, simultaneously, with no interference at all.

[sanjeevmk]

Yeah right, the first two cases don't make any sense. My mistake . Two threads on the same core can never access i/o at the same time.

Thanks for the replies.

Another doubt:
In multi core systems, each core has it's own scheduler , if I am not wrong. Does each instance of the scheduler run independently of the others?
Eg. If Process 1 on Core 1 is talking to the parallel port and Process 2 is doing heavy computation on Core 2, will Process 2 get affected in any way?

Thanks again.

[smwikipedia]

Yeah right, the first two cases don't make any sense. My mistake . Two threads on the same core can never access i/o at the same time.

Thanks for the replies.

Another doubt:
In multi core systems, each core has it's own scheduler , if I am not wrong. Does each instance of the scheduler run independently of the others?
Eg. If Process 1 on Core 1 is talking to the parallel port and Process 2 is doing heavy computation on Core 2, will Process 2 get affected in any way?

Thanks again.

I am not familiar with multi-core programming, but logically I think there should be some communication mechanism among different cores. And there should be some central authority (pardon me I don't know what jargon to use.) to be the judge. Otherwise, it would be total anarchy.

[sanjeevmk]

Yes, the kernel is the authority managing each instance of the scheduler. The schedulers run above the kernel and need to consult the kernel or take orders from it for their respective jobs.
What I need to know is the decision policies of the kernel when managing them, as in the example I have stated in my previous reply.

[smwikipedia]

In your example, I don't see any apprent relationship between process 1 and 2. So I don't think process 2 should be affected.

[gerryg400]

1. Two threads on same core access the same i/o port.
2. Two threads on same core access different i/o ports.

Actually 1 and 2 do need to be considered occasionally. Consider a driver that needs to read data from a device and multiple reads are required to get all the data. The thread needs to make sure that no other thread uses the port/device until the transaction is complete.

[bewing]

Yes, as gerryg400 says: on a device level, you still need locking or Device Manager protections, even on just one core.

And yes, the schedulers obviously need some method for being told which jobs are allocated to them, so they can be run. The schedulers do not necessarily have to talk directly to each other -- that is part of your design decision for your OS. The primary algorithms/considerations for choosing which jobs/threads to assign to which CPUs are called "load balancing" and "affinity". Look them up. The nextmost consideration is probably "thermal throttling".

[sanjeevmk]

Thanks a lot guys..that helps !!