Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #2564 > unrolled thread

< if but for and >

Back to article view | Back to comp.programming.threads

Contents

  < if but for and > philosofer <bertani.mauro.user@gmail.com> - 2014-07-28 07:22 -0700
    Re: < if but for and > Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-07-28 16:07 +0100
    Re: < if but for and > Kaz Kylheku <kaz@kylheku.com> - 2014-07-28 16:28 +0000

#2564 — < if but for and >

I reach a deadlock and I want to know if the condition is right.
I set i != 0 and i == 0.
Can some IT philosofer help me?








----------
IT customers speak all togheter english
italian philosofers translate over and over
thier lectures 

[toc] | [next] | [standalone]

#2565

philosofer <bertani.mauro.user@gmail.com> writes:

> I reach a deadlock and I want to know if the condition is right.
> I set i != 0 and i == 0.

That's not enough to go on.  You've written a condition that is false
(by which I mean never true, not "wrong") and that's all you tell us.
The general rule is this: post the code.

> Can some IT philosofer help me?

(Philosopher does not mean what you think it does in English.  I think
you probably mean "IT professor".)

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#2566

On 2014-07-28, philosofer <bertani.mauro.user@gmail.com> wrote:
> I reach a deadlock and I want to know if the condition is right.
> I set i != 0 and i == 0.
> Can some IT philosofer help me?

No; a deadlock is not defined as a logical contradiction or impossible
situation.

In a deadlock situation, there is no disagreement about the value of
any variable.

Loosely speaking, it is a situation in which one or more tasks in a system are
suspended, waiting for a situation which never arrives, because it is
impossible.

For instance i != 0, and a task is be waiting for i == 0.  But since i is
shared, setting i = 0 requires a mutex (setting i = 0 without a mutex would be
a bug), and it so happens that the waiting task is holding that mutex.
It won't unlock the mutex because it is waiting, and no other task will set
i = 0 because any task which tries will end up trapped, waiting for the mutex
(thereby ensnared in the deadlock).

In ordinary programming languages, variables can only have one stored value;
they hold whatever was most recently stored in them. Some integer i cannot
be simultaneously zero and nonzero. However, languages can have ambiguous
semantics, so that when we look at a program, we cannot predict whether i
will end up with the value 0 or nonzero.

In concurrent programming, a race condition can have such a consequence: the
final value of some variable depends on the execution order. Race conditions
are connected to deadlocks. Sometimes deadlocks are not easily reproduced,
because whether or not they occur hinges on a race condition. If deadlocks
always reproduced, they would be always found by developers rather than by
customers, as is often the case.

Languages can also incorporate logic reasoning via some kind of "logic
programming system". In a logic programming system, there can be a situation
where the system deduces that some variable i must be simultaneously zero and
nonzero.  At that point, the logic system would declare failure: the
propositions being considered lead to contradiction and so are false, as a
whole. (And perhaps that means that something else is true: like in a Reductio
ad Absurdum proof.) This kind of variable is not an ordinary variable
of a Von Neumann style programming language (a simple, named memory location
where a value can be stored).

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web