How to avoid deadlock?

[Dean Stevens]

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!

 

[Irrwahn Grausewitz]

(e-mail address removed) (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!

 

[Oliver S.]

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.

 

[Duke Robillard]

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

 

[Irrwahn Grausewitz]

Please do not crosspost to c.l.c, thanks; fup2 c.p.t set.

 

[August Derleth]

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.

 

[Dean Stevens]

<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]

Please do not crosspost to c.l.c, thanks; fup2 c.p.t set.

Moron Irrwahn Grausewitz, please get a life!

 

[Irrwahn Grausewitz]

(e-mail address removed) (Dean Stevens) wrote in

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

Which does not make it topical here.

 

[Alex]

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

 

[Arthur J. O'Dwyer]

(August Derleth) wrote...

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

 

[Irrwahn Grausewitz]

(e-mail address removed) (Dean Stevens) wrote in

Moron Irrwahn Grausewitz, please get a life!

*PLONK*

 

[Dean Stevens]

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?

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.

 

[David]

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?

 

[Oliver S.]

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

 

[Randy Howard]

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.

 

[richard]

idiot

I would have said troll, but you're probably right

 

[richard]

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?


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?


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?

 

[Randy Howard]

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.

 

[August Derleth]

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!