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! 20 10774 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.
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 <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. 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. 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.
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! 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.
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
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 ho******@hotmail.com (Dean Stevens) wrote in
<3f**************************@posting.google.com >: Moron Irrwahn Grausewitz, please get a life!
*PLONK*
--
Sic transit gloria mundi.
"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. 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?
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
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 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!
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
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 =---
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.
...."
"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 This discussion thread is closed Replies have been disabled for this discussion. Similar topics
1 post
views
Thread by Robert Brown |
last post: by
|
1 post
views
Thread by dawatson833 |
last post: by
|
7 posts
views
Thread by Andrew Mayo |
last post: by
|
3 posts
views
Thread by Nigel Robbins |
last post: by
|
1 post
views
Thread by Rohit Raghuwanshi |
last post: by
|
15 posts
views
Thread by Zeng |
last post: by
|
2 posts
views
Thread by Sumanth |
last post: by
|
reply
views
Thread by cwho.work |
last post: by
| | | | | | | | | | | |