Question on Process

I have question regarding the processes under Linux. It quite difficult to explain. but I will try. Since I am not really very good explaining things :)

Right, I have got a program which actually maps a register from the /dev/mem to the user space of the memory. And so alter to the register which is down in user memory which gets reflected to the hardware register.

What happened when I try run the same process in two different instances. So for example if "prog1" is the code file which does all the above mentioned job. What happens when I do

Shell 1

Code:

---

./prog1

---

Shell 2

Code:

---

./prog1

---

In the above case I have two shell running the same program. Will the kernel handle manage to write to the register through mutex control when there are two process pointing to the same memory location.

It would be difficult for me program to include the mutex around then, since i just get the image of that register into two different memory location when i get mapped through mmap function respectively.

Am I right here?

Thanks a lot guys

ssharish

It would be up to you to provide a mutex if one is necessary.

Though if your device register (as you put it) is just a single 32-bit location say, then it would be unnecessary.

http://linux.die.net/man/2/shmget
If you want a better way of sharing memory between multiple processes.

As Salem hinted, if you are doing single writes and single reads to one 32-bit register, then you can do it without any form of locks. If there are multiple registers that you need to access for a single operation, or you use "read-modify-write", e.g (*reg) += 4; on the register - or for example you have to read a status regisgter before writing to another register, then you do need some form of locks.

The other solution is to channel all your operations through a single place, e.g. a daemon (or simply a background process) - I'll call it a daemon for short. The daemon would use for example a named pipe or socket to receive requests, then perform one request at a time in an orderly fashion.

I hope this helps.

--
Mats

Thanks a lot for both of you for the information. It really helped in terms like IPC learning.

ssharish

>> ...is just a single 32-bit location say, then it would be unnecessary
>> if you are doing single writes and single reads to one 32-bit register, then you can do it without any form of locks

These are dangerous statements without qualification.

Reads and writes to aligned, CPU-sized data, on x86 architectures are atomic operations - in the sense that the execution of the entire read/write operation will not be pre-empted (by a hardware interrupt for instance). This may not be the case on other architectures, alignments, and other-sized data.

That being said, you can still get into trouble due to read/write re-orderings that arise from SMP cache coherency.

If the OP is truly using memory-mapped I/O registers, it may not be an x86 architecture.

gg

Quote:

---

Originally Posted by Codeplug

>> ...is just a single 32-bit location say, then it would be unnecessary
>> if you are doing single writes and single reads to one 32-bit register, then you can do it without any form of locks

These are dangerous statements without qualification.

Reads and writes to aligned, CPU-sized data, on x86 architectures are atomic operations - in the sense that the execution of the entire read/write operation will not be pre-empted (by a hardware interrupt for instance). This may not be the case on other architectures, alignments, and other-sized data.

That being said, you can still get into trouble due to read/write re-orderings that arise from SMP cache coherency.

If the OP is truly using memory-mapped I/O registers, it may not be an x86 architecture.

gg

---

You are indeed right, atomicity is only guaranteed if we have the address mapped uncached - if the memory location is cachable, there is very little chance that it will work at all.

Aligned addresses, using uncached access, should be atomic on 32-bit processors - as it is a single operation (at least the READ and WRITE will be - any arithmetics or other read-modify-write is almost certainly NOT so, even x86 is not guaranteed to do this, as there are so many ways the compiler may decide to perform this operaion) - of course, on a 16-bit processor, it is most likely NOT the case.

Why do you say that - there's plenty of modern hardware on x86 that use memory mapped registers - graphics cards, network cards, SATA controller, etc, etc. In fact, most hardware designed in the last 5-10 years is more likely to use MMIO than IOIO operations - it make the software easier to design, if nothing else, because with some care, it is possible to use struct's to define the register layout, which makes the use of the MMIO operations quite a lot easier.

--
Mats

Im should have asked this question before i acknowledged.

>Though if your device register (as you put it) is just a single 32-bit location say, then it would be unnecessary.
>writes and single reads to one 32-bit register, then you can do it without any form of locks.

How would you say that mutex is not required when just one register is been used. So for example if two process mapps the same register in two different location and anything altered in either of those two process will reflect one single register which inter looks i need mutex to protect the register. Am I right?

But I solved this problem both Salems and Maps advice through Interprocess Process Communication tech.

ssharish

Quote:

---

Originally Posted by ssharish2005

Im should have asked this question before i acknowledged.

>Though if your device register (as you put it) is just a single 32-bit location say, then it would be unnecessary.
>writes and single reads to one 32-bit register, then you can do it without any form of locks.

How would you say that mutex is not required when just one register is been used. So for example if two process mapps the same register in two different location and anything altered in either of those two process will reflect one single register which inter looks i need mutex to protect the register. Am I right?

But I solved this problem both Salems and Maps advice through Interprocess Process Communication tech.

ssharish

---

The fact that the register is mapped at two different (virtual) addresses in the different processes is irrelevant - the processor automatically translates that, and operates on the physical address, as long as the register is at a single physical address, it should be fine [1]. Since a read or write to a 32-bit register (on a 32-bit processor, address aligned to even 4 bytes, assuming caching is disabled) is an atomic operation in itself. However, there is no guarantee with regards to the order of one process reading and another process writing to the register. And there's absolutely no reason to believe that a write followed by a read can't be broken up by another write by another process, for example.

Without understanding what operations you are about to do on the register(s), it would be impossible to say whether you can get away without using some sort of lock, or not. The safe option is to use locks.

[1] It is of course conceivable to have hardware where one register is available at multiple physical addresses, for example because of limited decoding, - in which case you should ensure that all software uses only one of the different possible locations - anything else is playing with undefined behaviour.

--
Mats

>> Why do you say that...
DMA'd memory never crossed my mind - I blame the MMU-less architectures I've had to deal with in the past :)

gg

Quote:

---

Without understanding what operations you are about to do on the register(s), it would be impossible to say whether you can get away without using some sort of lock, or not. The safe option is to use locks.

---

Thanks Maps, that make sense. So its alway better to use locks!!

ssharish

Quote:

---

Originally Posted by ssharish2005

Thanks Maps, that make sense. So its alway better to use locks!!

ssharish

---

Yes. The key here is that you ensure that any access to the register(s) are done in a known way, where one process can't access a register in a way that "confuses" or "destroys" the access that another process is making. There's essentially two ways of achieving that:
1. Use some form of interprocess locks (mutex for example)
2. Use interprocess communication to send the data through a single point.

Which works best depends very much on what the application is... The lock method may have less overhead, but is also somewhat harder to implement.

--
Mats

I resolved this problem by inter process messaging. As you said before to keep one process to wite data on to the register. Like for example proc1 is the only process which has write access to the shared memory. If I need writing to that shared space, i need to send the data to proc1 process and that will write on behalf of proc2

If that makes sense. I used socket communication for that to achive. I could have used FIFO, Message Q or even semaphores as well :)

ssharish