Question on Process

This is a discussion on Question on Process within the C Programming forums, part of the General Programming Boards category; I have question regarding the processes under Linux. It quite difficult to explain. but I will try. Since I am ...

  1. #1
    Registered User ssharish2005's Avatar
    Join Date
    Sep 2005
    Location
    Cambridge, UK
    Posts
    1,682

    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
    Last edited by ssharish2005; 09-12-2007 at 06:48 PM.

  2. #2
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,484
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  3. #3
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  4. #4
    Registered User ssharish2005's Avatar
    Join Date
    Sep 2005
    Location
    Cambridge, UK
    Posts
    1,682
    Thanks a lot for both of you for the information. It really helped in terms like IPC learning.

    ssharish

  5. #5
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,659
    >> ...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

  6. #6
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Codeplug View Post
    >> ...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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  7. #7
    Registered User ssharish2005's Avatar
    Join Date
    Sep 2005
    Location
    Cambridge, UK
    Posts
    1,682
    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

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by ssharish2005 View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  9. #9
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,659
    >> 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

  10. #10
    Registered User ssharish2005's Avatar
    Join Date
    Sep 2005
    Location
    Cambridge, UK
    Posts
    1,682
    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

  11. #11
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by ssharish2005 View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  12. #12
    Registered User ssharish2005's Avatar
    Join Date
    Sep 2005
    Location
    Cambridge, UK
    Posts
    1,682
    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

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Problem with forking a process
    By Unitedroad in forum C Programming
    Replies: 10
    Last Post: 10-04-2007, 01:43 AM
  2. process programming
    By St0rM-MaN in forum Linux Programming
    Replies: 2
    Last Post: 09-15-2007, 07:53 AM
  3. Stopping Processes Question
    By brett in forum Linux Programming
    Replies: 3
    Last Post: 06-24-2007, 10:15 PM
  4. Replies: 12
    Last Post: 05-17-2003, 05:58 AM
  5. Hi all!, Another question, About NT Process
    By Pandora in forum Windows Programming
    Replies: 4
    Last Post: 03-19-2003, 11:24 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21