How to avoid deadlock?

Discussion in 'C Programming' started by Dean Stevens, Sep 1, 2003.

  1. Dean Stevens

    Dean Stevens Guest

    I have two processes: one holds a semaphore and the other waits for
    the semaphore. When the process which holds the semaphore is dead,
    the deadlock occurs. My question is there is anyway (in semaphore or
    operating systme) to avoid such situation? Thanks!
     
    Dean Stevens, Sep 1, 2003
    #1
    1. Advertising

  2. (Dean Stevens) wrote in
    <>:

    >I have two processes: one holds a semaphore and the other waits for
    >the semaphore. When the process which holds the semaphore is dead,
    >the deadlock occurs. My question is there is anyway (in semaphore or
    >operating systme) to avoid such situation? Thanks!


    The C programming language (the only topic in c.l.c) does not
    know anything about semaphores, amphores or whatever-phores.

    So, please don't crosspost this to c.l.c; thanks!

    --
    I wish life had a scroll-back buffer.
     
    Irrwahn Grausewitz, Sep 1, 2003
    #2
    1. Advertising

  3. Dean Stevens

    Oliver S. Guest

    > I have two processes: one holds a semaphore and the other waits for
    > the semaphore. When the process which holds the semaphore is dead,
    > the deadlock occurs. My question is there is anyway (in semaphore
    > or operating systme) to avoid such situation?


    When you're under Win32, this is quite easy; just do a WaitFor
    MultipleObjects on the semaphore as well as the process handle.
     
    Oliver S., Sep 1, 2003
    #3
  4. Dean Stevens wrote:
    > I have two processes: one holds a semaphore and the other waits for
    > the semaphore. When the process which holds the semaphore is dead,
    > the deadlock occurs. My question is there is anyway (in semaphore or
    > operating systme) to avoid such situation? Thanks!


    If you're using UNIX SysV semaphores, you might want to use the
    SEM_UNDO flag on your semget(). That tells the kernel to undo
    all a process's semops if the process dumps core.

    Duke
     
    Duke Robillard, Sep 2, 2003
    #4
  5. Duke Robillard <> wrote in <>:
    Please do not crosspost to c.l.c, thanks; fup2 c.p.t set.
    --
    Air is water with holes in it.
     
    Irrwahn Grausewitz, Sep 2, 2003
    #5
  6. (Dean Stevens) wrote in message news:<>...
    > I have two processes: one holds a semaphore and the other waits for
    > the semaphore. When the process which holds the semaphore is dead,
    > the deadlock occurs. My question is there is anyway (in semaphore or
    > operating systme) to avoid such situation? Thanks!


    <Fixed meaningless crosspost.>

    Semaphores, threads, and the very concept of processes (and,
    therefore, IPC) are not part of the C standard. Therefore, asking
    about it in comp.lang.c is not a very good way to get good answers.
    Next time, stick to a newsgroup focused on your specific topic and
    don't scatter your posts to the wind. It's better that one experienced
    person who knows what he's talking about see your post than a thousand
    irritated Usenetters who don't know the answer but do know about the
    etiquette of our fine medium.
     
    August Derleth, Sep 2, 2003
    #6
  7. Dean Stevens

    Dean Stevens Guest

    (August Derleth) wrote in message news:<>...
    > (Dean Stevens) wrote in message news:<>...
    > > I have two processes: one holds a semaphore and the other waits for
    > > the semaphore. When the process which holds the semaphore is dead,
    > > the deadlock occurs. My question is there is anyway (in semaphore or
    > > operating systme) to avoid such situation? Thanks!

    >
    > <Fixed meaningless crosspost.>
    >
    > Semaphores, threads, and the very concept of processes (and,
    > therefore, IPC) are not part of the C standard. Therefore, asking
    > about it in comp.lang.c is not a very good way to get good answers.
    > Next time, stick to a newsgroup focused on your specific topic and
    > don't scatter your posts to the wind. It's better that one experienced
    > person who knows what he's talking about see your post than a thousand
    > irritated Usenetters who don't know the answer but do know about the
    > etiquette of our fine medium.


    An expert C programmer has to deal with multi-process and
    multi-thread. I certainly don't expect you know them. You are just
    too stupid to be embarrassed.
     
    Dean Stevens, Sep 2, 2003
    #7
  8. Dean Stevens

    Dean Stevens Guest

    Irrwahn Grausewitz <> wrote in message news:<>...
    > Duke Robillard <> wrote in <>:
    > Please do not crosspost to c.l.c, thanks; fup2 c.p.t set.


    Moron Irrwahn Grausewitz, please get a life!
     
    Dean Stevens, Sep 2, 2003
    #8
  9. (Dean Stevens) wrote in
    <>:
    <SNIP>
    >An expert C programmer has to deal with multi-process and
    >multi-thread.

    Which does not make it topical here.

    --
    If you don't care where you are, then you ain't lost.
     
    Irrwahn Grausewitz, Sep 2, 2003
    #9
  10. Dean Stevens

    Alex Guest

    Dean Stevens <> wrote:
    > (August Derleth) wrote in message news:<>...
    >> (Dean Stevens) wrote in message news:<>...
    >> > I have two processes: one holds a semaphore and the other waits for
    >> > the semaphore. When the process which holds the semaphore is dead,
    >> > the deadlock occurs. My question is there is anyway (in semaphore or
    >> > operating systme) to avoid such situation? Thanks!

    >>
    >> <Fixed meaningless crosspost.>
    >>
    >> Semaphores, threads, and the very concept of processes (and,
    >> therefore, IPC) are not part of the C standard. Therefore, asking
    >> about it in comp.lang.c is not a very good way to get good answers.
    >> Next time, stick to a newsgroup focused on your specific topic and
    >> don't scatter your posts to the wind. It's better that one experienced
    >> person who knows what he's talking about see your post than a thousand
    >> irritated Usenetters who don't know the answer but do know about the
    >> etiquette of our fine medium.


    > An expert C programmer has to deal with multi-process and
    > multi-thread. I certainly don't expect you know them. You are just
    > too stupid to be embarrassed.


    Congratulations. You have just drastically decreased your chances of
    getting any kind of help from this newsgroup.

    There is a newsgroup dedicated to the subject that you want to discuss.
    comp.lang.c is not it. Read the FAQ before posting here again.

    Alex
     
    Alex, Sep 2, 2003
    #10
  11. On Tue, 2 Sep 2003, Dean Stevens wrote:
    >
    > (August Derleth) wrote...
    > > (Dean Stevens) wrote...
    > > >
    > > > I have two processes: one holds a semaphore and the other waits for
    > > > the semaphore. When the process which holds the semaphore is dead,
    > > > the deadlock occurs. My question is there is anyway (in semaphore or
    > > > operating systme) to avoid such situation? Thanks!

    > >
    > > <Fixed meaningless crosspost.>
    > >
    > > Semaphores, threads, and the very concept of processes (and,
    > > therefore, IPC) are not part of the C standard. Therefore, asking
    > > about it in comp.lang.c is not a very good way to get good answers.
    > > Next time, stick to a newsgroup focused on your specific topic and
    > > don't scatter your posts to the wind. It's better that one experienced
    > > person who knows what he's talking about see your post than a thousand
    > > irritated Usenetters who don't know the answer but do know about the
    > > etiquette of our fine medium.

    >
    > An expert C programmer has to deal with multi-process and
    > multi-thread.


    This is false, of course. The C paradigm is not threaded, nor
    oriented to deal with multiple processes. I would venture to say
    that between embedded systems, MS-DOS and variants, and command-line
    utilities, the vast majority of C programs do not have any *use*
    for threading.

    > I certainly don't expect you know them.


    Then why on earth did you ask in comp.lang.c? Go ask somewhere
    where threading is topical.

    Or, before all else fails (as it will, if you keep being so rude),
    try the World Wide Web. It's the part of the Internet with the
    pretty pictures. A lot of people put information there. There is
    a neat little company called "Google" that can search for things
    on the World Wide Web for you.

    http://www.google.com/search?q=semaphore deadlock tutorial&
    btnI=Im+Feeling+Lucky

    -Arthur
     
    Arthur J. O'Dwyer, Sep 2, 2003
    #11
  12. (Dean Stevens) wrote in
    <>:
    >Moron Irrwahn Grausewitz, please get a life!

    *PLONK*
    --
    Sic transit gloria mundi.
     
    Irrwahn Grausewitz, Sep 2, 2003
    #12
  13. Dean Stevens

    Dean Stevens Guest

    "Arthur J. O'Dwyer" <> wrote in message news:<>...
    > On Tue, 2 Sep 2003, Dean Stevens wrote:
    > >
    > > (August Derleth) wrote...
    > > > (Dean Stevens) wrote...
    > > > >
    > > > > I have two processes: one holds a semaphore and the other waits for
    > > > > the semaphore. When the process which holds the semaphore is dead,
    > > > > the deadlock occurs. My question is there is anyway (in semaphore or
    > > > > operating systme) to avoid such situation? Thanks!
    > > >
    > > > <Fixed meaningless crosspost.>
    > > >
    > > > Semaphores, threads, and the very concept of processes (and,
    > > > therefore, IPC) are not part of the C standard. Therefore, asking
    > > > about it in comp.lang.c is not a very good way to get good answers.
    > > > Next time, stick to a newsgroup focused on your specific topic and
    > > > don't scatter your posts to the wind. It's better that one experienced
    > > > person who knows what he's talking about see your post than a thousand
    > > > irritated Usenetters who don't know the answer but do know about the
    > > > etiquette of our fine medium.

    > >
    > > An expert C programmer has to deal with multi-process and
    > > multi-thread.

    >
    > This is false, of course. The C paradigm is not threaded, nor
    > oriented to deal with multiple processes. I would venture to say
    > that between embedded systems, MS-DOS and variants, and command-line
    > utilities, the vast majority of C programs do not have any *use*
    > for threading.


    I wanted an experienced C programmer to answer my question. Any
    non-trivial C programs have fork, signal, socket, or pthread. I don't
    know what C grograms you are talking about?

    > > I certainly don't expect you know them.

    >
    > Then why on earth did you ask in comp.lang.c? Go ask somewhere
    > where threading is topical.


    What a logic! Not every C programmer processes command-line utilities
    like you. People have built large distributed system by using C. I
    didn't expect you to answer my question. What can I expect you who
    even do not have any "use" for threading?

    > Or, before all else fails (as it will, if you keep being so rude),
    > try the World Wide Web. It's the part of the Internet with the
    > pretty pictures. A lot of people put information there. There is
    > a neat little company called "Google" that can search for things
    > on the World Wide Web for you.


    Stop raving! Go to a bookstore and pick up the Advanced Programming
    in the UNIX Environment before talking about programming.
     
    Dean Stevens, Sep 3, 2003
    #13
  14. Dean Stevens

    David Guest

    (Dean Stevens) wrote in message news:<>...
    > I have two processes: one holds a semaphore and the other waits for
    > the semaphore. When the process which holds the semaphore is dead,
    > the deadlock occurs. My question is there is anyway (in semaphore or
    > operating systme) to avoid such situation? Thanks!


    Who are you? What's wrong for someone to post a question in this
    group? If you cannot answer the question, just keep it quite. You
    don't have the right to determine what should be asked and what
    shouldn't. Are you Nazi from Germany? Or are you KKK from white
    trash?
     
    David, Sep 3, 2003
    #14
  15. Dean Stevens

    Oliver S. Guest

    > Who are you? What's wrong for someone to post a question in this
    > group? If you cannot answer the question, just keep it quite. You
    > don't have the right to determine what should be asked and what
    > shouldn't. Are you Nazi from Germany? Or are you KKK from white
    > trash?


    idiot
     
    Oliver S., Sep 3, 2003
    #15
  16. Dean Stevens

    Randy Howard Guest

    In article <>,
    says...
    > (Dean Stevens) wrote in message news:<>...
    > > I have two processes: one holds a semaphore and the other waits for
    > > the semaphore. When the process which holds the semaphore is dead,
    > > the deadlock occurs. My question is there is anyway (in semaphore or
    > > operating systme) to avoid such situation? Thanks!

    >
    > Who are you? What's wrong for someone to post a question in this
    > group? If you cannot answer the question, just keep it quite. You
    > don't have the right to determine what should be asked and what
    > shouldn't. Are you Nazi from Germany? Or are you KKK from white
    > trash?


    You've just invoked Godwin's Law. Too bad. Look it up. Google
    is a good place to start.

    It's silly season again. I.e., a new batch of CS101 students have
    arrived on campus, been assigned homework problems, and granted
    internet accounts.

    FYI: There are thousands of Usenet groups. My particular ISP's NNTP
    server currently lists 30266 of them. In order to not have them all turn
    into an AOL chatroom w/the associated chaos, many technical groups try
    to stay focused on a particular topic or set of topics.

    comp.lang.c is for the discussion of programming in STANDARD C.
    That is to say, the C language that is guaranteed to work on
    all platforms with a conforming C implementation.

    comp.programming.threads is where people discuss threaded programming.
    The scope is a bit broader there, as discussions of Windows threading,
    POSIX threads, and pretty much any other threading model you care to
    mention is considered on topic there.

    Platform-specific questions are handled in other groups. There is a long
    list of groups specific to various platforms. Most good newsreaders
    will allow you to search the list of all available groups for a particular
    string, such as "msdos", "windows", "win32", "linux", "unix", etc.

    --
    Randy Howard _o
    2reply remove FOOBAR \<,
    ______________________()/ ()______________________________________________
    SCO Spam-magnet:
     
    Randy Howard, Sep 3, 2003
    #16
  17. Dean Stevens

    richard Guest

    On 3 Sep 2003 03:16:11 GMT, "Oliver S." <> wrote:

    >> Who are you? What's wrong for someone to post a question in this
    >> group? If you cannot answer the question, just keep it quite. You
    >> don't have the right to determine what should be asked and what
    >> shouldn't. Are you Nazi from Germany? Or are you KKK from white
    >> trash?

    >
    > idiot


    I would have said troll, but you're probably right
     
    richard, Sep 3, 2003
    #17
  18. Dean Stevens

    richard Guest

    On 2 Sep 2003 19:24:07 -0700, (Dean Stevens) wrote:

    >"Arthur J. O'Dwyer" <> wrote in message news:<>...
    >> On Tue, 2 Sep 2003, Dean Stevens wrote:
    >> >
    >> > (August Derleth) wrote...
    >> > > (Dean Stevens) wrote...
    >> > > >
    >> > > > I have two processes: one holds a semaphore and the other waits for
    >> > > > the semaphore. When the process which holds the semaphore is dead,
    >> > > > the deadlock occurs. My question is there is anyway (in semaphore or
    >> > > > operating systme) to avoid such situation? Thanks!
    >> > >
    >> > > <Fixed meaningless crosspost.>
    >> > >
    >> > > Semaphores, threads, and the very concept of processes (and,
    >> > > therefore, IPC) are not part of the C standard. Therefore, asking
    >> > > about it in comp.lang.c is not a very good way to get good answers.
    >> > > Next time, stick to a newsgroup focused on your specific topic and
    >> > > don't scatter your posts to the wind. It's better that one experienced
    >> > > person who knows what he's talking about see your post than a thousand
    >> > > irritated Usenetters who don't know the answer but do know about the
    >> > > etiquette of our fine medium.
    >> >
    >> > An expert C programmer has to deal with multi-process and
    >> > multi-thread.

    >>
    >> This is false, of course. The C paradigm is not threaded, nor
    >> oriented to deal with multiple processes. I would venture to say
    >> that between embedded systems, MS-DOS and variants, and command-line
    >> utilities, the vast majority of C programs do not have any *use*
    >> for threading.

    >
    >I wanted an experienced C programmer to answer my question. Any
    >non-trivial C programs have fork, signal, socket, or pthread. I don't
    >know what C grograms you are talking about?
    >
    >> > I certainly don't expect you know them.

    >>
    >> Then why on earth did you ask in comp.lang.c? Go ask somewhere
    >> where threading is topical.

    >
    >What a logic! Not every C programmer processes command-line utilities
    >like you. People have built large distributed system by using C. I
    >didn't expect you to answer my question. What can I expect you who
    >even do not have any "use" for threading?
    >
    >> Or, before all else fails (as it will, if you keep being so rude),
    >> try the World Wide Web. It's the part of the Internet with the
    >> pretty pictures. A lot of people put information there. There is
    >> a neat little company called "Google" that can search for things
    >> on the World Wide Web for you.

    >
    >Stop raving! Go to a bookstore and pick up the Advanced Programming
    >in the UNIX Environment before talking about programming.


    Out of curiousity, what do you hope to accomplish by posting an off-topic
    message to a newsgroup and then being rude to people who point this out to you?
     
    richard, Sep 3, 2003
    #18
  19. Dean Stevens

    Randy Howard Guest

    In article <>, howto800
    @hotmail.com says...
    > Any non-trivial C programs have fork, signal, socket, or pthread.


    A very large number of non-trivial C programs have none of the above. I
    suspect a nice neural network backprop algorithm or cascade-correlation
    network implementation might throw a lot of experienced C programmers into
    the ditch. No strict need for any of the above, yet far, far from
    trivial. The same thing can be said for a lot of types of programs. An
    encryption program might be another good example.

    > What a logic! Not every C programmer processes command-line utilities
    > like you. People have built large distributed system by using C.


    True they may use the C language, plus platform specific extensions.
    There are newsgroups where that is very much on topic.

    > What can I expect you who even do not have any "use" for threading?


    I don't know about the person you refer to above, but I have a lot of
    "use" for threading, every day. In fact, 90% of the software I've
    written in the last two years has been threaded. It's also portable
    across quite a few platforms, but can not be written in standard c.
    So, I just don't talk about it in this newsgroup because it is
    inappropriate here. Walk down the hall to comp.programming.threads
    for that.

    > Stop raving! Go to a bookstore and pick up the Advanced Programming
    > in the UNIX Environment before talking about programming.


    I'd guess that at least 75% of the regulars have that book already.
    Unfortunately, a lot of what's in the book is discussed in other
    newsgroups, not this one.

    Your behavior here is no different than if you walked into a bakery and
    demanded that someone sell you a Bridgeport milling machine, followed by
    you screaming at the teller behind the counter for "being too stupid" to
    be able to assist you with one. Even if the teller was married to a
    machine shop supply salesman and knew a great deal about them, I doubt she
    would feel it was appropriate to hold up those wanting to buy bread to
    discuss it with you for a few hours.

    --
    Randy Howard _o
    2reply remove FOOBAR \<,
    ______________________()/ ()______________________________________________
    SCO Spam-magnet:
     
    Randy Howard, Sep 3, 2003
    #19
  20. (Dean Stevens) wrote in message news:<>...
    > (August Derleth) wrote in message news:<>...
    > > It's better that one experienced
    > > person who knows what he's talking about see your post than a thousand
    > > irritated Usenetters who don't know the answer but do know about the
    > > etiquette of our fine medium.

    >
    > An expert C programmer has to deal with multi-process and
    > multi-thread. I certainly don't expect you know them. You are just
    > too stupid to be embarrassed.


    Heh.

    Heh heh heh.

    HAW HAW!

    You just can't /buy/ comedy like that, folks!
     
    August Derleth, Sep 3, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Wolfgang Denk

    Aspnet Recycled - False Deadlock - need fix

    Wolfgang Denk, Aug 11, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    339
    Wolfgang Denk
    Aug 11, 2003
  2. Alexander Malkis
    Replies:
    8
    Views:
    532
    Alexander Malkis
    Apr 14, 2004
  3. Roger23
    Replies:
    2
    Views:
    1,015
    Roger23
    Oct 12, 2006
  4. sk
    Replies:
    5
    Views:
    357
    Alfred
    Dec 22, 2006
  5. M D

    avoid deadlock for EJB

    M D, Dec 21, 2006, in forum: Java
    Replies:
    5
    Views:
    567
Loading...

Share This Page