By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,750 Members | 1,471 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,750 IT Pros & Developers. It's quick & easy.

How to avoid deadlock?

P: n/a
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!
Nov 13 '05 #1
Share this Question
Share on Google+
20 Replies


P: n/a
ho******@hotmail.com (Dean Stevens) wrote in
<3f************************@posting.google.com>:
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.
Nov 13 '05 #2

P: n/a
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

Nov 13 '05 #3

P: n/a
Duke Robillard <du**@io.com> wrote in <3F**************@io.com>:
Please do not crosspost to c.l.c, thanks; fup2 c.p.t set.
--
Air is water with holes in it.
Nov 13 '05 #4

P: n/a
ho******@hotmail.com (Dean Stevens) wrote in message news:<3f************************@posting.google.co m>...
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.
Nov 13 '05 #5

P: n/a
li***************@yahoo.com (August Derleth) wrote in message news:<b6*************************@posting.google.c om>...
ho******@hotmail.com (Dean Stevens) wrote in message news:<3f************************@posting.google.co m>...
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.
Nov 13 '05 #6

P: n/a
Irrwahn Grausewitz <ir*****@freenet.de> wrote in message news:<ak********************************@4ax.com>. ..
Duke Robillard <du**@io.com> wrote in <3F**************@io.com>:
Please do not crosspost to c.l.c, thanks; fup2 c.p.t set.


Moron Irrwahn Grausewitz, please get a life!
Nov 13 '05 #7

P: n/a
ho******@hotmail.com (Dean Stevens) wrote in
<3f**************************@posting.google.com >:
<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.
Nov 13 '05 #8

P: n/a
Dean Stevens <ho******@hotmail.com> wrote:
li***************@yahoo.com (August Derleth) wrote in message news:<b6*************************@posting.google.c om>...
ho******@hotmail.com (Dean Stevens) wrote in message news:<3f************************@posting.google.co m>...
> 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

Nov 13 '05 #9

P: n/a

On Tue, 2 Sep 2003, Dean Stevens wrote:

(August Derleth) wrote...
ho******@hotmail.com (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=semap...lock+tutorial&
btnI=Im+Feeling+Lucky

-Arthur
Nov 13 '05 #10

P: n/a
ho******@hotmail.com (Dean Stevens) wrote in
<3f**************************@posting.google.com >:
Moron Irrwahn Grausewitz, please get a life!

*PLONK*
--
Sic transit gloria mundi.
Nov 13 '05 #11

P: n/a
"Arthur J. O'Dwyer" <aj*@andrew.cmu.edu> wrote in message news:<Pi************************************@unix5 0.andrew.cmu.edu>...
On Tue, 2 Sep 2003, Dean Stevens wrote:

(August Derleth) wrote...
ho******@hotmail.com (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.
Nov 13 '05 #12

P: n/a
ho******@hotmail.com (Dean Stevens) wrote in message news:<3f************************@posting.google.co m>...
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?
Nov 13 '05 #13

P: n/a
In article <e4**************************@posting.google.com >,
di********@yahoo.com says...
ho******@hotmail.com (Dean Stevens) wrote in message news:<3f************************@posting.google.co m>...
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: po********@sco.com
Nov 13 '05 #14

P: n/a
In article <3f**************************@posting.google.com >, 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: po********@sco.com
Nov 13 '05 #15

P: n/a
ho******@hotmail.com (Dean Stevens) wrote in message news:<3f**************************@posting.google. com>...
li***************@yahoo.com (August Derleth) wrote in message news:<b6*************************@posting.google.c om>...
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!
Nov 13 '05 #16

P: n/a
Dean Stevens wrote:
Stop raving! Go to a bookstore and pick up the Advanced Programming
in the UNIX Environment before talking about programming.


*plonk*


Brian Rodenborn
Nov 13 '05 #17

P: n/a
On 2 Sep 2003 19:24:07 -0700, in comp.lang.c , ho******@hotmail.com
(Dean Stevens) wrote:
"Arthur J. O'Dwyer" <aj*@andrew.cmu.edu> wrote in message news:<Pi************************************@unix5 0.andrew.cmu.edu>...
On Tue, 2 Sep 2003, Dean Stevens wrote:

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?


Probably because you apparently have no clue at all what C is, or what
an expert C programmer is either. Clue: its nothing to do with unix.
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.


And this relevant how? clue: its not. the topic of CLC is C, not
system specific extensions to C.
Stop raving! Go to a bookstore and pick up the Advanced Programming
in the UNIX Environment before talking about programming.


Read your post. See that word in all-caps? Is that word spelt "C"? No?
Well, then what the fsck has it got to do with C then? Free clue no 3:
all the C world is not a unix box. In fact only a very very small
fraction of it is.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 13 '05 #18

P: n/a
Would you like to use the class library "http://mdthread.org/"
(Message-Driven Thread API for the Java Programming Language)?
The FAQ contains the following statement.
"A major advantage of the mdthread API over Doug Lea's utilities is
that a program based on the mdthread API is automatically
deadlock-safe.
...."
Nov 13 '05 #19

P: n/a

"Markus Elfring" <Ma************@web.de> wrote in message
news:40**************************@posting.google.c om...
Would you like to use the class library "http://mdthread.org/"
(Message-Driven Thread API for the Java Programming Language)?
The FAQ contains the following statement.
"A major advantage of the mdthread API over Doug Lea's utilities is
that a program based on the mdthread API is automatically
deadlock-safe.
..."


What cracks me up the most is their comparison to Win32 UI threads. They
say their implementation is portable because it's "written entirely in
Java". But that means it's portable across platforms but tied to one
language. Win32 UI threads work in any language but aren't protable across
platforms. Whether that makes one more portable than the other is a tricky
question, but it's not a "yes/no" bullet item.

DS
Nov 13 '05 #20

P: n/a
I suggest to read the following documents to see that Java is more
portable because other languages can access its rich functionality,
too.

1. Lesson: Interacting with Java from the Native Side
http://java.sun.com/docs/books/tutor...ing/index.html

2. Scripting Pages in Java Web Applications
http://www.jcp.org/en/jsr/detail?id=223

3. The Tcl/Java Project
http://tcljava.sourceforge.net/
Nov 13 '05 #21

This discussion thread is closed

Replies have been disabled for this discussion.