need help finding a "possible" deadlock in simple application...
Chris M. Thomasson
http://webpages.charter.net/appcore/misc/diner_c.html
Apparently, Szabolcs Ferenczi says this deadlocks as-is. Well, I am having
kind of a hard time determining where the bug is. Can you help me? Can you
please execute the code a couple of times and see if it runs to completion?
I am having a hard time getting it to deadlock. I guess I will code it up in
Relacy for a last resort! ;^)
The code as-is runs a try-lock algorithm. Here is the relevant function:
__________________________________________________________________
void
diner_eat_trylock(
diner* const _this
) {
int status, i = 1, old;
puts("********** diner_eat_trylock **********");
/* lock in reverse-order on purpose... */
while(! (status =
pthread_mutex_lock(&_this->forks[i]->lock))) {
old = i;
i = (old) ? 0 : 1;
if (! (status =
pthread_mutex_trylock(&_this->forks[i]->lock))) {
break;
}
assert(old != i);
if (status != EBUSY) {
break;
}
if ((status =
pthread_mutex_unlock(&_this->forks[old]->lock))) {
break;
}
sched_yield();
}
if (status) { assert(! status); abort(); }
}
__________________________________________________________________
There is only one unlock function:
__________________________________________________________________
void
diner_eat_unlock(
diner* const _this
) {
int status, i = 1;
/* unlock in reverse-order... */
for(; i > -1; --i) {
if ((status =
pthread_mutex_unlock(&_this->forks[i]->lock))) {
break;
}
}
if (status) { assert(! status); abort(); }
}
__________________________________________________________________
I can't see a deadlock off hand wrt the interaction between those two
functions. Here is the thread entry procedure, its setup so that there is a
thread per-diner:
__________________________________________________________________
void*
diner_thread(
void* this_state
) {
int i = 0;
diner* const _this = this_state;
diner_wait(_this, i, "Has Been Seated!");
for(++i; pg_run && i < DINER_ITERATIONS(); ++i) {
if (i % 2) {
diner_think(_this, i);
} else {
diner_eat(_this, i);
}
}
pg_run = 0;
diner_wait(_this, i, "Has Left The Table!");
return 0;
}
__________________________________________________________________
`pg_run' is a simple volatile variable used to shutdown all threads when one
diner is finished. The program can run with any number of diners at the
table: 1, 2, 3, 4 or 5. You can try it by tweaking the following functions:
__________________________________________________________________
void diner_startup(
diner _this[5]
) {
int status, i = 0;
pg_run = 1;
for(; i < 5; ++i) {
diner_sort_assert(&_this[i]);
if ((status =
pthread_create(&_this[i].tid, 0,
diner_thread, &_this[i]))) {
break;
}
}
if (status) { assert(! status); abort(); }
puts("diner_startup");
}
void diner_shutdown(
diner _this[5]
) {
int status, i = 0;
for(; i < 5; ++i) {
if ((status =
pthread_join(_this[i].tid, 0))) {
break;
}
}
if (status) { assert(! status); abort(); }
puts("diner_shutdown");
}
__________________________________________________________________
Just switch the 5 in the functions above two a lower number to get both of
the functions to spawn that many diners. The only function which ever calls
the locks/unlock functions is `diner_eat()' which is as follows:
__________________________________________________________________
void
diner_eat(
diner* const _this,
int const seq
) {
/* lock */
if (_this->flags & DINER_FLAG_SORTLOCK()) {
diner_eat_sortlock(_this);
} else {
diner_eat_trylock(_this);
}
/* wait */
diner_wait(_this, seq, "Is Eating Spaghettii!");
/* unlock */
diner_eat_unlock(_this);
}
__________________________________________________________________
The only thing that comes to mind is that he did not link to the thread-safe
version of the crt. However, I still would greatly appreciate any feedback.
Thank you so very much for your time and energy!
Szabolcs Ferenczi
Relacy Race Detector: Make your synchronization correct!
http://groups.google.ru/group/relacy/web
Chris M. Thomasson
"Szabolcs Ferenczi" <szabolcs...@gmail.com> wrote in message
news:a422d4c9-0d0c-45af...@k16g2000hsf.googlegroups.com...
On Oct 10, 11:30 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > Here is the code which solves the dining philosophers problem:
> >
> > http://webpages.charter.net/appcore/misc/diner_c.html
> >
> > Apparently, Szabolcs Ferenczi says this deadlocks as-is. Well, I am
> > having
> > kind of a hard time determining where the bug is. Can you help me? Can
> > you
> > please execute the code a couple of times and see if it runs to
> > completion?
> > I am having a hard time getting it to deadlock. I guess I will code it
> > up in
> > Relacy for a last resort! ;^)
> Relacy Race Detector: Make your synchronization correct!
> http://groups.google.ru/group/relacy/web
If I code this in Relacy, and it works, well, something foul is going on
here.
Chris M. Thomasson
"Szabolcs Ferenczi" <szabolcs...@gmail.com> wrote in message
news:a422d4c9-0d0c-45af...@k16g2000hsf.googlegroups.com...
> > Here is the code which solves the dining philosophers problem:
> >
> > http://webpages.charter.net/appcore/misc/diner_c.html
> >
> > Thank you so very much for your time and energy!
> Relacy Race Detector: Make your synchronization correct!
> http://groups.google.ru/group/relacy/web
Apparently, there is recursion on a non-recursive mutex. I need to decipher
the Relacy output some more, and make sure I translated the algorithm
properly.
Chris M. Thomasson
news:SpQHk.7$0e...@newsfe09.iad...
Ahh I make error in translation. Well, so far Relacy is telling me that the
algorihtms WORKS as it. Let me run it through some different scheduler
models. Then I will post the Relacy code in a new thread called "Relacy
proves algorithm correct!"... If it reports error, I will post "Relacy Saves
The Day!".
Szabolcs Ferenczi
> "Szabolcs Ferenczi" <szabolcs.feren...@gmail.com> wrote in message
Well, because of the spaghetti it is difficult to spot but:
void
diner_eat_trylock(
diner* const _this
) {
int status, i = 1, old;
puts("********** diner_eat_trylock **********");
/* lock in reverse-order on purpose... */
while(! (status =
pthread_mutex_lock(&_this->forks[i]->lock))) { // <--- this is
recursively locked
old = i;
i = (old) ? 0 : 1;
if (! (status =
pthread_mutex_trylock(&_this->forks[i]->lock))) {
break;
}
[...]
Dmitriy V'jukov
wrote:
Szabolcs, I am really pleased that you used Relacy Race Detector. Did
you have any problems with it? What is your impression?
Dmitriy V'jukov
Szabolcs Ferenczi
> On 11 ÏËÔ, 01:27, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
Do not be mistaken. I have never used it and I do not need to use it.
I only remembered that he has always been keen on this trial and error
tool. Interestingly, if this tool does not tell him anything, that
means nothing. It only tells him that he was not lucky. He can never
be sure about the spaghetti code.
That is all folks.
Best Regards,
Szabolcs
Chris M. Thomasson
[...]
NO! Your wrong. Did you notice the alternating indexes? See, the reason
Relacy said there was a recursive lock on a non-recursive mutex is because I
fuc%ked up in the translation from the original algorithm to the Relacy
version. I used the `old' variable in the pthread_mutex_trylock line. I
corrected the and now the Relacy version uses identical algorithm. So, I
think your wrong. I can't get it to deadlock, Relacy can't get it to
deadlock... Well, what's going on?
Chris M. Thomasson
"Dmitriy V'jukov" <dvy...@gmail.com> wrote in message
news:abd1375d-0483-46d6...@m73g2000hsh.googlegroups.com...
Well Dmitriy, Relacy proves that my algorithm is correct. Here is the Relacy
translation:
http://webpages.charter.net/appcore/misc/relacy/diner_relacy_cpp.html
Szabolcs is either linking against the wrong library, or there is some
"dishonesty" going on. I can't get my program to deadlock, Relacy can't get
it to deadlock. Can you get it to deadlock Dmitriy? Here is original code:
http://webpages.charter.net/appcore/misc/diner_c.html
When I first translated I made an error in the trylock function. And BAM!
Relacy says recursive lock! So, I compare original to translation and look
at Relacy output directed into MSVC (very nice feature BTW), and BAM! I find
my stupid error. So, I make fix, and compare it to original again, and their
identical algorithms. Well, thanks you Relacy, I can say that Szabolcs must
be mistaken when he says there is a error in my algorithm. I asked him for a
list of thread stacks and variable state, and he refuses to give it to me
because it probably does not exist.
Chris M. Thomasson
> > wrote:
> >
> >
> >
> > > Relacy Race Detector: Make your synchronization
> > > correct!http://groups.google.ru/group/relacy/web
> >
> > Szabolcs, I am really pleased that you used Relacy Race Detector. Did
> > you have any problems with it? What is your impression?
> >
> > Dmitriy V'jukov
> Do not be mistaken. I have never used it and I do not need to use it.
Are you sure about that?
> I only remembered that he has always been keen on this trial and error
> tool. Interestingly, if this tool does not tell him anything, that
> means nothing. It only tells him that he was not lucky. He can never
> be sure about the spaghetti code.
> That is all folks.
Well, Relacy says my diners algorithm works. What say you? Do you think
there is a bug in Relacy?
Szabolcs Ferenczi
> "Szabolcs Ferenczi" <szabolcs.feren...@gmail.com> wrote in message
>
> news:db0dca1d-90b7-4a12...@u75g2000hsf.googlegroups.com...
> On Oct 11, 12:51 am, "Dmitriy V'jukov" <dvyu...@gmail.com> wrote:
>
> > > wrote:
>
> > > > Relacy Race Detector: Make your synchronization
> > > > correct!http://groups.google.ru/group/relacy/web
>
> > > Szabolcs, I am really pleased that you used Relacy Race Detector. Did
> > > you have any problems with it? What is your impression?
>
> > > Dmitriy V'jukov
> > Do not be mistaken. I have never used it and I do not need to use it.
>
> Are you sure about that?
Quite sure.
> > I only remembered that he has always been keen on this trial and error
> > tool. Interestingly, if this tool does not tell him anything, that
> > means nothing. It only tells him that he was not lucky. He can never
> > be sure about the spaghetti code.
> > That is all folks.
>
> Well, Relacy says my diners algorithm works. What say you? Do you think
> there is a bug in Relacy?
Might be there is a bug in Relacy. Who proved it correct? Who
acceptance tested it and where is the test? If Relacy tells you that
your spaghetti works, that only means that it could not find the bug.
It definitely gets frozen after some time.
As some people mentioned it in comp.programming.threads already,
nobody can trust your code which most of the time is some hack. You
are a good hacker, though.
Best Regards,
Szabolcs
Chris M. Thomasson
On Oct 11, 1:21 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > "Szabolcs Ferenczi" <szabolcs.feren...@gmail.com> wrote in message
> >
> > news:db0dca1d-90b7-4a12...@u75g2000hsf.googlegroups.com...
> > On Oct 11, 12:51 am, "Dmitriy V'jukov" <dvyu...@gmail.com> wrote:
> >
> > > > wrote:
> >
> > > > > Relacy Race Detector: Make your synchronization
> > > > > correct!http://groups.google.ru/group/relacy/web
> >
> > > > Szabolcs, I am really pleased that you used Relacy Race Detector.
> > > > Did
> > > > you have any problems with it? What is your impression?
> >
> > > > Dmitriy V'jukov
> > > Do not be mistaken. I have never used it and I do not need to use it.
> >
> > Are you sure about that?
> Quite sure.
> > > I only remembered that he has always been keen on this trial and error
> > > tool. Interestingly, if this tool does not tell him anything, that
> > > means nothing. It only tells him that he was not lucky. He can never
> > > be sure about the spaghetti code.
> > > That is all folks.
> >
> > Well, Relacy says my diners algorithm works. What say you? Do you think
> > there is a bug in Relacy?
> Might be there is a bug in Relacy. Who proved it correct? Who
> acceptance tested it and where is the test? If Relacy tells you that
> your spaghetti works, that only means that it could not find the bug.
> It definitely gets frozen after some time.
> As some people mentioned it in comp.programming.threads already,
> nobody can trust your code which most of the time is some hack. You
> are a good hacker, though.
Well, could you please give me all the threads call stacks, and the state of
the local variables within the function that it deadlocks in? Perhaps I fix
bug in translation to Relacy. Please compare the try_lock, sort_lock and
unlock functions in the Relacy version:
http://webpages.charter.net/appcore/misc/relacy/diner_relacy_cpp.html
with the original version:
http://webpages.charter.net/appcore/misc/diner_c.html
AFAICT, they are the same basic algorihtm indeed. I know that the try_lock
function does not recursively lock the mutexs. I am totally confused! Please
help me find this deadlock Szabolcs! Also, can others PLEASE run the
program? Thanks!
;^?
Dmitriy V'jukov
> Might be there is a bug in Relacy. Who proved it correct? Who
> acceptance tested it and where is the test? If Relacy tells you that
> your spaghetti works, that only means that it could not find the bug.
> It definitely gets frozen after some time.
Ok, lets test Relacy - please, provide description how deadlock can
occur. And I will investigate why Relacy didn't catch it.
Dmitriy V'jukov
Szabolcs Ferenczi
> Here is the code which solves the dining philosophers problem:
>
> http://webpages.charter.net/appcore/misc/diner_c.html
>
> Apparently, Szabolcs Ferenczi says this deadlocks as-is. Well, I am having
> kind of a hard time determining where the bug is. Can you help me?
Apparently you omitted a flush before the final prompt and the program
apparently stopped in the middle of the output. However, it was
waiting for the final enter that you notoriously put to the end of
your program. You did not insert a flush before you asked for the
enter so the program apparently was frozen.
int
exit_prompt(
int const status,
char const* const msgbuf
) {
printf("%s", msgbuf);
+ fflush(stdout);
getchar();
return status;
}
This apparently fixes your program on MinGW, although, the output
device is a shared resource that deserves a mutex and some
synchronization too.
Best Regards,
Szabolcs
Chris M. Thomasson
On Oct 10, 11:30 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > Here is the code which solves the dining philosophers problem:
> >
> > http://webpages.charter.net/appcore/misc/diner_c.html
> >
> > Apparently, Szabolcs Ferenczi says this deadlocks as-is. Well, I am
> > having
> > kind of a hard time determining where the bug is. Can you help me?
> Apparently you omitted a flush before the final prompt and the program
> apparently stopped in the middle of the output. However, it was
> waiting for the final enter that you notoriously put to the end of
> your program. You did not insert a flush before you asked for the
> enter so the program apparently was frozen.
Sorry about that; well, at least the problem was not in the sync algorithm!
:^D
> int
> exit_prompt(
> int const status,
> char const* const msgbuf
> ) {
> printf("%s", msgbuf);
> + fflush(stdout);
> getchar();
> return status;
> }
> This apparently fixes your program on MinGW, although, the output
> device is a shared resource that deserves a mutex and some
> synchronization too.
wrap all calls to `printf()' in a mutex and place a `fflush()' around it.
Well, I guess that makes sense.
Chris M. Thomasson
There no problem. Apparently, the output to the console was buffered and
never got committed to the screen before the final `getchar()' blocked the
calling thread on i/o. Nothing wrong with the sync algorithm, which is why
Relacy did not detect anything whatsoever:
http://groups.google.com/group/comp.programming.threads/msg/c0a3f71a83bd2d07
Adding a call to `fflush()' before `getchar()' solved the problem. I know my
synchronization algorithm with solves the dining philosophers problem works
indeed.
Szabolcs Ferenczi
>
> http://webpages.charter.net/appcore/misc/diner_c.html
> However, I still would greatly appreciate any feedback.
Let us see.
I had a closer look at your code. Although it is spaghetti as it is,
you perhaps unconsciously implemented the hierarchical resource
allocation solution to the canonical problem. There are other
solutions as well. You can look them up from any school book about
concurrent programming or about operating system principles.
Your trick is in lines
{ { &the_forks[0], &the_forks[4] },
"David",
DINER_FLAG_TRYLOCK(), 300 }
That is, instead of keeping the allocation scheme of the fork
resources uniform like this
{ { &the_forks[4], &the_forks[0] },
"David",
DINER_FLAG_TRYLOCK(), 300 }
you brake the sequence and one of the participants will reach
for the right side fork while all the others reach for he left side
forks. This works well with both of your locking functions.
You seemingly experienced with some kind of error correction code but
later on you just inserted an assert and left it behind as a dead
code.
void
diner_sort_assert(
diner* const _this
) {
fork* const first = _this->forks[0];
if (first > _this->forks[1]) {
assert(first < _this->forks[1]);
_this->forks[0] = _this->forks[1];
_this->forks[1] = first;
}
}
The hierarchical ordering of the fork resources is not needed by
both of your locking scheme, however. If you just disable your hard
wired guard `diner_sort_assert' and you just allocate the fork
resources to the philosophers uniformly like this:
{ { &the_forks[4], &the_forks[0] },
"David",
DINER_FLAG_TRYLOCK(), 300 }
your DINER_FLAG_SORTLOCK version will deadlock. Just check it with
your race detector. The other one, however, will not deadlock.
The DINER_FLAG_TRYLOCK version does not rely on the hierarchical
resource allocation since you have unconsciously implemented a
backtracking mechanism. If a participant cannot grab the second fork
resource, it backtracks, i.e. releases the first fork and tries to
seize the resources anew. So this version does not deadlock with the
uniform distribution of fork resources.
However, you have obviously forgotten about starvation and both of
your algorithm is clearly prone to it. You can see it if you insert
some delays around, then, eager participants can make starve the
others to death.
Best Regards,
Szabolcs
Chris M. Thomasson
"Szabolcs Ferenczi" <szabolcs...@gmail.com> wrote in message
news:3a6fc73f-37c7-42e8...@s1g2000prg.googlegroups.com...
> > Here is the code which solves the dining philosophers problem:
> >
> > http://webpages.charter.net/appcore/misc/diner_c.html
> >
> > Apparently, Szabolcs Ferenczi says this deadlocks as-is. Well, I am
> > having
> > kind of a hard time determining where the bug is. Can you help me?
> Apparently you omitted a flush before the final prompt and the program
> apparently stopped in the middle of the output. However, it was
> waiting for the final enter that you notoriously put to the end of
> your program. You did not insert a flush before you asked for the
> enter so the program apparently was frozen.
> [...]
[...]
> This apparently fixes your program on MinGW, although, the output
> device is a shared resource that deserves a mutex and some
> synchronization too.
Well, how does anyone know what a C lib does in the presence of a
multi-threaded environment? The C lib that I use on win32 does "seem" to
flush buffers before the call to `getchar()'. Its totally undefined
behavior. Therefore, do you suggest that one surround EVERY call to a C lib
function with sync primitives? Well, before one does that, I suggest they
read the documentation of their compiler and find out if their std lib calls
are thread-safe or not.
However, this origin problem dealt with buffering data that was not
outputted to the screen before a call to `getchar()'. AFAICT, this can, and
will, happen on system that have fully thread-safe C libs or not. I make
mistake.
Thank you Szabolcs for having the patience to figure it out. I really
appreciate your time and energy Sir!
:^D
Szabolcs Ferenczi
> On 11 ÏËÔ, 03:23, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
>
> > Might be there is a bug in Relacy. Who proved it correct? Who
> > your spaghetti works, that only means that it could not find the bug.
> > It definitely gets frozen after some time.
>
> Ok, lets test Relacy - please, provide description how deadlock can
> occur. And I will investigate why Relacy didn't catch it.
Well, I do not care for testing it until it accepts obvious
concurrency hazards. At least you can investigate right now why Relacy
did not catch a potential problem in the code, namely, multiple
threads manipulating an unprotected shared variable:
static int volatile pg_run = 0;
...
void*
diner_thread(
void* this_state
) {
int i = 0;
diner* const _this = this_state;
diner_wait(_this, i, "Has Been Seated!");
for(++i; pg_run && i < DINER_ITERATIONS(); ++i) {
if (i % 2) {
diner_think(_this, i);
} else {
diner_eat(_this, i);
}
}
pg_run = 0;
diner_wait(_this, i, "Has Left The Table!");
return 0;
}
Best Regards,
Szabolcs
Dmitriy V'jukov
wrote:
> > Ok, lets test Relacy - please, provide description how deadlock can
> > occur. And I will investigate why Relacy didn't catch it.
>
> Well, I do not care for testing it until it accepts obvious
> concurrency hazards. At least you can investigate right now why Relacy
> did not catch a potential problem in the code, namely, multiple
> threads manipulating an unprotected shared variable:
>
> static int volatile pg_run = 0;
Relacy didn't catch it, because it is correct from point of view of
current C++ draft. And it's correct from point of view of current C++
draft because it is correct from point of view of most available
hardware.
Relacy is not intended for beginners, so it can't report error only
because there is concurrent conflicting accesses to variable. Assume
your are implementing mutex *itself* on new platform, how are you
going to implement it w/o concurrent conflicting accesses?!
Although all this is correct iff pg_run is declared as
std::atomic<int> (which I think the case), i.e. you are saying that
this variable is intended for concurrent access. If you will declare
it as just var<int>, then Relacy do will catch error as data race on
variable pg_run.
So I think everything is Ok with Relacy.
Dmitriy V'jukov
Szabolcs Ferenczi
> On 12 ÏËÔ, 15:56, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
> wrote:
>
> > > Ok, lets test Relacy - please, provide description how deadlock can
> > > occur. And I will investigate why Relacy didn't catch it.
>
> > Well, I do not care for testing it until it accepts obvious
> > concurrency hazards. At least you can investigate right now why Relacy
> > did not catch a potential problem in the code, namely, multiple
> > threads manipulating an unprotected shared variable:
>
> > static int volatile pg_run = 0;
>
> Relacy didn't catch it, because it is correct from point of view of
> current C++ draft.
First of all, it is not a C++ code but a C code. Besides, my point was
not that it is
declared volatile, that is allowed. Rather, the point is that variable
`pg_run' is accessed concurrently, so it is the source of data race,
despite Relacy was not able to detect it.
> And it's correct from point of view of current C++
> draft because it is correct from point of view of most available
> hardware.
Uhum. Most. Then, Relacy is not only a trial and error tool but it can
make some sense only _on most_ available hardware platform. You
obviously do not want to specify on which hardware platform it is
applicable and on which it is not, do you?
> Relacy is not intended for beginners,
Who else then? Experienced programmers? They _mostly_ do not need it.
> so it can't report error only
> because there is concurrent conflicting accesses to variable.
Hmmm... what else then? "only because there is concurrent conflicting
accesses to variable" Only because ...
> Assume
> your are implementing mutex *itself* on new platform, how are you
> going to implement it w/o concurrent conflicting accesses?!
It is well known for quite some decades now that you need hardware
support for
it. You might want to solve it with help of some plain variable but it
is not adequate and you will learn about it from your own experience
once you did not learn anything from the experience of others.
> Although all this is correct iff pg_run is declared as
> std::atomic<int> (which I think the case),
Negative. If you were just to have a look at the code you could
realised that it is not the case. I can help you once again:
static int volatile pg_run = 0;
According to the C++ standard, volatile is not the same as
std::atomic<int> yet.
> i.e. you are saying that
> this variable is intended for concurrent access.
I do not know what his intent was but de facto this variable is
accessed concurrently. Relacy could have figured it out.
> If you will declare
> it as just var<int>, then Relacy do will catch error as data race on
> variable pg_run.
I will not declare it that way but you should check it out with the
author of that code.
> So I think everything is Ok with Relacy.
Yeah. You think it. Obviously. What else? That is why I would not use
it.---You faced with a problem and instead of fixing it you explain
it.
Best Regards,
Szabolcs
Dmitriy V'jukov
> > > > Ok, lets test Relacy - please, provide description how deadlock can
> > > > occur. And I will investigate why Relacy didn't catch it.
>
> > > Well, I do not care for testing it until it accepts obvious
> > > concurrency hazards. At least you can investigate right now why Relacy
> > > did not catch a potential problem in the code, namely, multiple
> > > threads manipulating an unprotected shared variable:
>
> > > static int volatile pg_run = 0;
>
> > Relacy didn't catch it, because it is correct from point of view of
> > current C++ draft.
>
> First of all, it is not a C++ code but a C code. Besides, my point was
> not that it is
> declared volatile, that is allowed. Rather, the point is that variable
> `pg_run' is accessed concurrently, so it is the source of data race,
> despite Relacy was not able to detect it.
Data races are perfectly Ok on all hardware platforms. And they have
perfectly defined semantics. They are prohibited only in some abstract
models.
I think that you just confuse low-level data races (which is the case
here) with application level data races (which can lead to things like
corrupted data structures).
> > And it's correct from point of view of current C++
> > draft because it is correct from point of view of most available
> > hardware.
>
> Uhum. Most. Then, Relacy is not only a trial and error tool but it can
> make some sense only _on most_ available hardware platform. You
> obviously do not want to specify on which hardware platform it is
> applicable and on which it is not, do you?
You don't guess one more time. I do. Relacy is applicable on all
platforms which support C++0x (no for now) AND on all platforms for
which one is able to create mapping to C++0x (all for now).
> > Relacy is not intended for beginners,
>
> Who else then? Experienced programmers? They _mostly_ do not need it.
Aha-ha-ha-ha.
Me armed with Relacy was able to find a number of errors in algorithms
which used in VERY respected PRODUCTION libraries written by VERY
RESPECTED and SMART people. And many other VERY smart people use other
verification software like SPIN, CHESS etc.
Although this is not applied to people who able to think only in terms
of mutexes and condition variables created for them by mummies and who
think that it's limit of coolness.
> > so it can't report error only
> > because there is concurrent conflicting accesses to variable.
>
> Hmmm... what else then? "only because there is concurrent conflicting
> accesses to variable" Only because ...
It's not an error by itself. Try to read some theory to begin with.
> > Assume
> > your are implementing mutex *itself* on new platform, how are you
> > going to implement it w/o concurrent conflicting accesses?!
>
> It is well known for quite some decades now that you need hardware
> support for
> it. You might want to solve it with help of some plain variable but it
> is not adequate and you will learn about it from your own experience
> once you did not learn anything from the experience of others.
And how are you going to get access to that support? If not by
executing some instructions in some programming language? I am
curious. Are you going to pool some levers?
> > Although all this is correct iff pg_run is declared as
> > std::atomic<int> (which I think the case),
>
> Negative. If you were just to have a look at the code you could
> realised that it is not the case. I can help you once again:
>
> static int volatile pg_run = 0;
>
> According to the C++ standard, volatile is not the same as
> std::atomic<int> yet.
Nobody is writing code against pure C/C++. People are writing code
against PLATFORM which is hardware + compiler + OS.
Chris used PLATFORM means, you have to learn such basic things.
> > i.e. you are saying that
> > this variable is intended for concurrent access.
>
> I do not know what his intent
His intent is reflected in code. I can't help you here. Try to learn
basic programming skills.
> was but de facto this variable is
> accessed concurrently. Relacy could have figured it out.
>
> > If you will declare
> > it as just var<int>, then Relacy do will catch error as data race on
> > variable pg_run.
>
> I will not declare it that way but you should check it out with the
> author of that code.
>
> > So I think everything is Ok with Relacy.
>
> Yeah. You think it. Obviously. What else? That is why I would not use
> it.---You faced with a problem and instead of fixing it you explain
> it.
Don't get despair. Relacy also has some basic support for amateur
multi-threaded programmers who can only use mutexes and condition
variables and for whom low-level data race is the end of the world.
Dmitriy V'jukov
Chris M. Thomasson
Indeed. Here is the translated version of my original program to Relacy:
http://webpages.charter.net/appcore/misc/relacy/diner_relacy_cpp.html
The analog of `pg_run' is `diners_test::m_run' which is defined as:
rl::atomic<bool> m_run;
Everything's okay.
Szabolcs Ferenczi
> On 12 ÏËÔ, 18:36, Szabolcs Ferenczi <szabolcs.feren...@gmail.com> >
[...]
> > First of all, it is not a C++ code but a C code. Besides, my point was
> > not that it is
> > declared volatile, that is allowed. Rather, the point is that variable
> > `pg_run' is accessed concurrently, so it is the source of data race,
> > despite Relacy was not able to detect it.
>
> Data races are perfectly Ok on all hardware platforms.
Maybe ok for you just to save your buggy tool.
[...]
> > > so it can't report error only
> > > because there is concurrent conflicting accesses to variable.
>
> > Hmmm... what else then? "only because there is concurrent conflicting
> > accesses to variable" Only because ...
>
> It's not an error by itself.
Oh no, certainly not. How could it be?
[...]
> > > Assume
> > > your are implementing mutex *itself* on new platform, how are you
> > > going to implement it w/o concurrent conflicting accesses?!
>
> > It is well known for quite some decades now that you need hardware
> > support for
> > it. You might want to solve it with help of some plain variable but it
> > is not adequate and you will learn about it from your own experience
> > once you did not learn anything from the experience of others.
>
> And how are you going to get access to that support? If not by
> executing some instructions in some programming language? I am
> curious. Are you going to pool some levers?
You should learn some basic stuff, my young friend. You can get access
to that support by looking up hardware implemented machine
instructions for atomic access. One such an instruction is test-and-
set (TAS) and another is check-and-swap (CAS). Without these you
cannot do what you claim you can do.
However, my genius young friend, come back to me and report your
implementation of mutexes on a new hardware platform without any
hardware support.
> > > Although all this is correct iff pg_run is declared as
> > > std::atomic<int> (which I think the case),
>
> > Negative. If you were just to have a look at the code you could
> > realised that it is not the case. I can help you once again:
>
> > static int volatile pg_run = 0;
>
> > According to the C++ standard, volatile is not the same as
> > std::atomic<int> yet.
>
> Nobody is writing code against pure C/C++. People are writing code
> against PLATFORM which is hardware + compiler + OS.
> Chris used PLATFORM means, you have to learn such basic things.
He just hacks some spaghetti code. He is a very good hacker, though.
Others, of course, write code "against pure C/C++."
You are trying to save him since your trial and error tool could not
catch his beginner mistake.
> > > i.e. you are saying that
> > > this variable is intended for concurrent access.
>
> > I do not know what his intent
>
> His intent is reflected in code. I can't help you here.
Well, buddy, you wanted to learn about his intent. It is your turn to
consult him. You do not have to help me.
[...]
> > > So I think everything is Ok with Relacy.
>
> > Yeah. You think it. Obviously. What else? That is why I would not use
> > it.---You faced with a problem and instead of fixing it you explain
> > it.
>
> Don't get despair. Relacy also has some basic support for amateur
> multi-threaded programmers
That is why your friend is in love with it. It helps him a lot.
Best Regards,
Szabolcs
Dmitriy V'jukov
wrote:
> > > First of all, it is not a C++ code but a C code. Besides, my point was
> > > not that it is
> > > declared volatile, that is allowed. Rather, the point is that variable
> > > `pg_run' is accessed concurrently, so it is the source of data race,
> > > despite Relacy was not able to detect it.
>
> > Data races are perfectly Ok on all hardware platforms.
>
> Maybe ok for you just to save your buggy tool.
Feel free to tell us about models where data races are not Ok. One
well-know is POSIX. Anything else?
Models where data races are Ok: x86, Itanium, PPC, SPARC, Alpha, ARM,
Java, .NET.
Please, don't confuse low-level data races with application bugs this
time.
Dmitriy V'jukov
Dmitriy V'jukov
wrote:
> > > > so it can't report error only
> > > > because there is concurrent conflicting accesses to variable.
>
> > > Hmmm... what else then? "only because there is concurrent conflicting
> > > accesses to variable" Only because ...
>
> > It's not an error by itself.
>
> Oh no, certainly not. How could it be?
Do you even saw implementation of synchronization primitives?
If yes, look one more time, but now more carefully, and you will see
low-level data races there.
Dmitriy V'jukov
Dmitriy V'jukov
> > > > your are implementing mutex *itself* on new platform, how are you
> > > > going to implement it w/o concurrent conflicting accesses?!
>
> > > It is well known for quite some decades now that you need hardware
> > > support for
> > > it. You might want to solve it with help of some plain variable but it
> > > is not adequate and you will learn about it from your own experience
> > > once you did not learn anything from the experience of others.
>
> > And how are you going to get access to that support? If not by
> > executing some instructions in some programming language? I am
> > curious. Are you going to pool some levers?
>
> You should learn some basic stuff, my young friend. You can get access
> to that support by looking up hardware implemented machine
> instructions for atomic access. One such an instruction is test-and-
> set (TAS) and another is check-and-swap (CAS). Without these you
> cannot do what you claim you can do.
>
> However, my genius young friend, come back to me and report your
> implementation of mutexes on a new hardware platform without any
> hardware support.
I was not saying that it's possible to implement synchronization
primitive w/o hardware support. However such support can be wrapped by
OS, or C/C++ *implementations*. Usually it's the case.
Btw, I am able to implement mutex w/o TAS/CAS/XCHG (any atomic RMW). I
was posting implementations here. Also you can take a look on
Peterson's mutual exclusion algorithm. Most C/C++ implementations
(gcc, icc, msvc) provide all necessary support to implement it.
Dmitriy V'jukov
Dmitriy V'jukov
wrote:
> > > According to the C++ standard, volatile is not the same as
> > > std::atomic<int> yet.
>
> > Nobody is writing code against pure C/C++. People are writing code
> > against PLATFORM which is hardware + compiler + OS.
> > Chris used PLATFORM means, you have to learn such basic things.
>
> He just hacks some spaghetti code. He is a very good hacker, though.
> Others, of course, write code "against pure C/C++."
It's impossible to write multi-threaded code in pure C/C++. Don't you
think that somebody is writing multi-threaded code "in C/C++"?
If you don't hear about any multi-threaded C/C++ software, I can point
you to some.
Dmitriy V'jukov
Dmitriy V'jukov
> > > it.---You faced with a problem and instead of fixing it you explain
> > > it.
>
> > Don't get despair. Relacy also has some basic support for amateur
> > multi-threaded programmers
>
> That is why your friend is in love with it. It helps him a lot.
You strip significant part:
"... who can only use mutexes and condition
variables and for whom low-level data race is the end of the world."
It's not him. It's someone else.
Dmitriy V'jukov
Dmitriy V'jukov
> I think that you just confuse low-level data races (which is the case
> here) with application level data races (which can lead to things like
> corrupted data structures).
Do you understand difference between them?
Dmitriy V'jukov
Chris M. Thomasson
[...]
> > > First of all, it is not a C++ code but a C code. Besides, my point was
> > > not that it is
> > > declared volatile, that is allowed. Rather, the point is that variable
> > > `pg_run' is accessed concurrently, so it is the source of data race,
> > > despite Relacy was not able to detect it.
> >
> > Data races are perfectly Ok on all hardware platforms.
> Maybe ok for you just to save your buggy tool.
There is such thing as an innocuous data-race.
[...]
> > > > so it can't report error only
> > > > because there is concurrent conflicting accesses to variable.
> >
> > > Hmmm... what else then? "only because there is concurrent conflicting
> > > accesses to variable" Only because ...
> >
> > It's not an error by itself.
> Oh no, certainly not. How could it be?
It was a simple volatile flag to shut down the program. Why should I use a
condvar to do this? I mean, no data depended on the state of the flag, so
what's wrong; exactly?
[...]
> > > > Assume
> > > > your are implementing mutex *itself* on new platform, how are you
> > > > going to implement it w/o concurrent conflicting accesses?!
> >
> > > It is well known for quite some decades now that you need hardware
> > > support for
> > > it. You might want to solve it with help of some plain variable but it
> > > is not adequate and you will learn about it from your own experience
> > > once you did not learn anything from the experience of others.
> >
> > And how are you going to get access to that support? If not by
> > executing some instructions in some programming language? I am
> > curious. Are you going to pool some levers?
> You should learn some basic stuff, my young friend. You can get access
> to that support by looking up hardware implemented machine
> instructions for atomic access. One such an instruction is test-and-
> set (TAS) and another is check-and-swap (CAS). Without these you
> cannot do what you claim you can do.
Your mistaken; sorry. Please check the following code implementing Petersons
algorithm:
http://groups.google.com/group/comp.programming.threads/browse_thread/thread/c49c0658e2607317
Where are the atomic RMW instructions?
Also, look at Dekker's algorithm. Did you know that you can do rw-mutex
without using any atomic RMW and membars for readers? Dmitriy created an
interesting algorithm to that effect by taking advantage of synchronization
epoch detection.
> However, my genius young friend, come back to me and report your
> implementation of mutexes on a new hardware platform without any
> hardware support.
He never wrote that. On the other hand, _you_ basically wrote that its
impossible to implement a mutex without TAS and CAS. You obviously did not
know that there are various synchronization algorithms out there that do not
use any of those instructions...
> > > > Although all this is correct iff pg_run is declared as
> > > > std::atomic<int> (which I think the case),
> >
> > > Negative. If you were just to have a look at the code you could
> > > realised that it is not the case. I can help you once again:
> >
> > > static int volatile pg_run = 0;
> >
> > > According to the C++ standard, volatile is not the same as
> > > std::atomic<int> yet.
> >
> > Nobody is writing code against pure C/C++. People are writing code
> > against PLATFORM which is hardware + compiler + OS.
> > Chris used PLATFORM means, you have to learn such basic things.
> He just hacks some spaghetti code. He is a very good hacker, though.
> Others, of course, write code "against pure C/C++."
> You are trying to save him since your trial and error tool could not
> catch his beginner mistake.
There was no mistake; using a volatile flag to shutdown threads when NO
data-state is dependant on the flag-state is harmless.
> > > > i.e. you are saying that
> > > > this variable is intended for concurrent access.
> >
> > > I do not know what his intent
> >
> > His intent is reflected in code. I can't help you here.
> Well, buddy, you wanted to learn about his intent. It is your turn to
> consult him. You do not have to help me.
If you cannot figure out why the `pg_run' flag was in there, and if you
cannot understand that I am not making any data state depend on it, well
that your problem, not mine. You need the help Sir; professional help
indeed.
[...]
> > > > So I think everything is Ok with Relacy.
> >
> > > Yeah. You think it. Obviously. What else? That is why I would not use
> > > it.---You faced with a problem and instead of fixing it you explain
> > > it.
> >
> > Don't get despair. Relacy also has some basic support for amateur
> > multi-threaded programmers
> That is why your friend is in love with it. It helps him a lot.
Relacy is a nice tool to have around. It does help.
Dmitriy V'jukov
> > Who else then? Experienced programmers? They _mostly_ do not need it.
>
> Aha-ha-ha-ha.
> Me armed with Relacy was able to find a number of errors in algorithms
> which used in VERY respected PRODUCTION libraries written by VERY
> RESPECTED and SMART people. And many other VERY smart people use other
> verification software like SPIN, CHESS etc.
Do you aware of the fact that Linux kernel developers use multi-
threading verification tools, .NET TPL developers use multi-threading
verification tools, Intel TBB developers use multi-threading
verification tools, many other developers concerned with serious
multi-threading (not with just kindergarten "protect it with mutex"
multi-threading) do use multi-threading verification tools?
Dmitriy V'jukov
Chris M. Thomasson
On Oct 10, 11:30 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> Here is the code which solves the dining philosophers problem:
>
> http://webpages.charter.net/appcore/misc/diner_c.html
[...]
> However, I still would greatly appreciate any feedback.
> Let us see.
> I had a closer look at your code. Although it is spaghetti as it is,
> you perhaps unconsciously implemented the hierarchical resource
> allocation solution to the canonical problem.
Ummmm. No, see, I implemented the hierarchical locking scheme on purpose;
sorry but I know all about it. How else would the `diner_sort_lock()'
function work? I added the `diner_sort_assert()' just in case somebody
rearranged the fork order. It would automatically sort the forks on a
per-diner bases to comply with global locking order.
> There are other
> solutions as well. You can look them up from any school book about
> concurrent programming or about operating system principles.
I know.
> Your trick is in lines
>
> { { &the_forks[0], &the_forks[4] },
> "David",
> DINER_FLAG_TRYLOCK(), 300 }
> That is, instead of keeping the allocation scheme of the fork
> resources uniform like this
> { { &the_forks[4], &the_forks[0] },
> "David",
> DINER_FLAG_TRYLOCK(), 300 }
> you brake the sequence and one of the participants will reach
> for the right side fork while all the others reach for he left side
> forks. This works well with both of your locking functions.
Indeed.
> You seemingly experienced with some kind of error correction code but
> later on you just inserted an assert and left it behind as a dead
> code.
> void
> diner_sort_assert(
> diner* const _this
> ) {
> fork* const first = _this->forks[0];
> if (first > _this->forks[1]) {
> assert(first < _this->forks[1]);
> _this->forks[0] = _this->forks[1];
> _this->forks[1] = first;
> }
> }
Actually, this `assert()' is useless because it will never trip. The
preceding if statement already ensures that the `assert()' will be pass. I
don't exactly know why I put it in there.
> The hierarchical ordering of the fork resources is not needed by
> both of your locking scheme, however. If you just disable your hard
> wired guard `diner_sort_assert' and you just allocate the fork
> resources to the philosophers uniformly like this:
> { { &the_forks[4], &the_forks[0] },
> "David",
> DINER_FLAG_TRYLOCK(), 300 }
> your DINER_FLAG_SORTLOCK version will deadlock. Just check it with
> your race detector. The other one, however, will not deadlock.
OF COURSE!!! Why would you disable the `diner_sort_assert()' function? Its
there for a very important reason! If you switch the fork order, the
function will automatically take care of the sorting. Why don't you try
switching the forks to the diner `David' and keep the `diner_sort_assert()'
intact like its suppose to be.
> The DINER_FLAG_TRYLOCK version does not rely on the hierarchical
> resource allocation since you have unconsciously implemented a
> backtracking mechanism.
Again, I implemented that way on purpose! I know what I am doing wrt
creating locking algorithms.
> If a participant cannot grab the second fork
> resource, it backtracks, i.e. releases the first fork and tries to
> seize the resources anew. So this version does not deadlock with the
> uniform distribution of fork resources.
Indeed. However, it does not try to grab the resources in the same order on
each failure. I alternate indexes on failure. This can improve performance.
> However, you have obviously forgotten about starvation and both of
> your algorithm is clearly prone to it. You can see it if you insert
> some delays around, then, eager participants can make starve the
> others to death.
The sort_lock algorithm could introduce some starvation. However, the
try_lock algorithm is definitely better when it comes to fairness. Also, I
could add some state variables which could attempt to detect which diners
are becoming fat pigs. This information can then be used to induce some
fairness across the table...
;^)
Dmitriy V'jukov
> > > > Hmmm... what else then? "only because there is concurrent conflicting
> > > > accesses to variable" Only because ...
>
> > > It's not an error by itself.
> > Oh no, certainly not. How could it be?
>
> It was a simple volatile flag to shut down the program. Why should I use a
> condvar to do this? I mean, no data depended on the state of the flag, so
> what's wrong; exactly?
I think that Szabolcs just don't understand what is "data depended on
flag". Although it will be interesting to hear one more funny answer
from him :)
> > > And how are you going to get access to that support? If not by
> > > executing some instructions in some programming language? I am
> > > curious. Are you going to pool some levers?
> > You should learn some basic stuff, my young friend. You can get access
> > to that support by looking up hardware implemented machine
> > instructions for atomic access. One such an instruction is test-and-
> > set (TAS) and another is check-and-swap (CAS). Without these you
> > cannot do what you claim you can do.
>
> Your mistaken; sorry. Please check the following code implementing Petersons
> algorithm:
>
> http://groups.google.com/group/comp.programming.threads/browse_thread...
>
> Where are the atomic RMW instructions?
There are no mutexes, there are no condition variables... let's see
how Szabolcs will comment on algorithm which he is unable to
understand :))
It's already very funny, and it's going to become even more funny. I
hope that Szabolcs will not retire :)))
Dmitriy V'jukov
Szabolcs Ferenczi
> The sort_lock algorithm could introduce some starvation.
Both are prone to starvation. You simply failed to address that issue.
> However, the
> try_lock algorithm is definitely better when it comes to fairness.
Well, additionally this one is prone to _livelock,_ I guess.
Best Regards,
Szabolcs
Chris M. Thomasson
On Oct 12, 8:01 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > The sort_lock algorithm could introduce some starvation.
> Both are prone to starvation. You simply failed to address that issue.
try_lock is not as bad as sort_lock, however, yes; I did not care about
letting fat as$ diners stuff their faces.
> > However, the
> > try_lock algorithm is definitely better when it comes to fairness.
> Well, additionally this one is prone to _livelock,_ I guess.
Indeed.
BTW, please show where you snip text from posts! I need to post a link to
the post you butchered:
http://groups.google.com/group/comp.programming.threads/msg/17d06b3f5744e5f1
You snip, and don't tell anybody. Well, please not that some racy state
variables can attempt to solve problems. See, the state variables do not
need to be atomic. This race-condition is preferable. Why lock that type of
state? Do you want to see an example?
Szabolcs Ferenczi
> BTW, please show where you snip text from posts!
I do that only whenever it is necessary. However, if it is clear that
the answer contains only the relevant part of the text, only the
losers will cry for the snip marks.
Best Regards,
Szabolcs
Chris M. Thomasson
On Oct 13, 12:07 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > BTW, please show where you snip text from posts!
> I do that only whenever it is necessary.
GRRRR!#@$#@!$#@!$@#%#@
;^?
You decide when the reader DESERVES proper context notations? If the reader
sees a snip notation, well, he is prompted to read up-thread to gain proper
context. If you omit them, to CHEAT them out of getting the full picture!
Not cool!!!!!
GRRRR!
> However, if it is clear that
> the answer contains only the relevant part of the text, only the
> losers will cry for the snip marks.
Oh come on! If you snip, PLEASE TRY TO replace the deleted text with
something like:
[...]
[snipped]
[cut]
-<>-
WHATEVER!
When you cut/delete/omit text _without_ ____marking____ the cut, you can end
up __misleading__ people and __twisting__ meanings of the __entire__
discussion at hand. Sir, let me be FRANK!
ONLY LOSERS CUT TEXT WITHOUT TELLING ANYBODY.
Are you __afraid__ of making an explicit cut mark because it might make
somebody travel unthread to gain full context. You snip, without telling
ANYBODY WHAT you snipped! What a loser; sorry about that!
;^(...
I can try to butcher your comments in a fashion which makes you look like a
MORON. Luckily, you do all of the work for me!!!
;^|
Szabolcs Ferenczi
> Oh come on! If you snip, PLEASE TRY TO replace the deleted text with
> something like:
>
> [...]
>
> [snipped]
>
> [cut]
>
> -<>-
>
> WHATEVER!
I do that when it is reasonable. I won't do that just because some
limited capability hacker cannot reason about his hack and pretends
that he cannot remember what he has written couple of minutes ago.
I always keep that part that I am answering so that any reader can
follow what is happening.
Best Regards,
Szabolcs
Szabolcs Ferenczi
> "Szabolcs Ferenczi" <szabolcs.feren...@gmail.com> wrote in message
> > You seemingly experienced with some kind of error correction code but
> > later on you just inserted an assert and left it behind as a dead
> > code.
> > void
> > diner_sort_assert(
> > diner* const _this
> > ) {
> > fork* const first = _this->forks[0];
> > if (first > _this->forks[1]) {
> > assert(first < _this->forks[1]);
> > _this->forks[0] = _this->forks[1];
> > _this->forks[1] = first;
> > }
> > }
>
> Actually, this `assert()' is useless because it will never trip. The
> preceding if statement already ensures that the `assert()' will be pass. I
> don't exactly know why I put it in there.
Well, the assert always fires if the preceding if statement selects
the statement body but the code following the assert is dead. Well,
you are not aware of it since you never have unit tests and you never
care about the test coverage of your code.
Obviously you were playing with fixing the "wrong" resource allocation
and later on you rather asserted in that case but you have forgotten
to remove the dead code. You know, once you start to grow a spaghetti
code, you yourself cannot find your way in it.
Best Regards,
Szabolcs
Szabolcs Ferenczi
> Well, please not[e] that some racy state
> variables can attempt to solve problems.
Maybe you attempt but you do not solve the problem with it.
> See, the state variables do not
> need to be atomic. This race-condition is preferable. Why lock that type of
> state? Do you want to see an example?
It is not only about atomicity but it is about that the volatile
keyword does not guarantee you that that variable will serve you as an
atomic one. Namely you will have a visibility problem. We have
discussed this issue several times on comp.programming.threads, the
last time here:
"Would race condition like this be harmful?"
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/163bfa36e27c0c94/360ea387df5c8409#360ea387df5c8409
There you claimed that you are aware of it:
<quote from="http://groups.google.com/group/comp.programming.threads/
msg/360ea387df5c8409">
> The 'volatile' keyword only disables compiler optimizations.
I know.
> It does not disable CPU or hardware optimizations that are safe on
> single-threaded
> code.
Indeed.
</quote>
So there you said `indeed' but here you forget about it.
Hmmm...: "This race-condition is preferable."---you say.
Only you and your friend prefer race conditions in the situation when
you must escape since you cannot argue. Interestingly, however, your
friend claims to make a race detector tool, i.e. he is going to detect
what he prefers. Crazy guys.
Best Regards,
Szabolcs
Chris M. Thomasson
On Oct 13, 12:07 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > Well, please not[e] that some racy state
> > variables can attempt to solve problems.
> Maybe you attempt but you do not solve the problem with it.
It wouldn't hurt. ;^)
> > See, the state variables do not
> > need to be atomic. This race-condition is preferable. Why lock that type
> > of
> > state? Do you want to see an example?
> It is not only about atomicity but it is about that the volatile
> keyword does not guarantee you that that variable will serve you as an
> atomic one.
I know. I was thinking about creating a counter per-diner which is
incremented under the mutex, and read-only from others without the mutex.
> Namely you will have a visibility problem.
Visibility problem; where? I don't care if the counter of how many times a
diner has eaten is read from other diners without a mutex because it does
not have to be 100% accurate; stale data is fine. Think of RCU reading stale
data from a shared collection. This is perfectly fine for a lot of
algorithms.
> We have
> discussed this issue several times on comp.programming.threads, the
> last time here:
> "Would race condition like this be harmful?"
> http://groups.google.com/group/comp.programming.threads/browse_frm/thread/163bfa36e27c0c94/360ea387df5c8409#360ea387df5c8409
There you claimed that you are aware of it:
[...]
> So there you said `indeed' but here you forget about it.
> Hmmm...: "This race-condition is preferable."---you say.
Yeah. Its perfectly fine in this case, just like its perfectly fine for RCU
to read stale data. You don't seem to get it. The race-condition is
preferable because I don't care if the read-only portion of the algorithm
observes stale counter values. No need to lock the diner mutex to read the
variable. This is a race-condition that I can live with. Heck, RCU is
designed around this condition. RCU does not need to take a read lock to
access a collection because it already understood by users that the
algorithm can observed stale, but coherent, data.
> Only you and your friend prefer race conditions in the situation when
> you must escape since you cannot argue.
Huh? I am arguing that there is such a thing as an innocuous race-condition.
> Interestingly, however, your
> friend claims to make a race detector tool, i.e. he is going to detect
> what he prefers. Crazy guys.
I don't think you are all that experienced with creating synchronization
algorithms from scratch. Relacy helps in this department big time. Just like
when you wrote that is basically impossible to create a mutex without using
atomic RMW instructions. You think "oh, well, no atomics, there is a
race-condition!". Can you even understand Petersons algorithm? Just because
there is a race-condition on the turn variable does not mean the algorihtm
is broken. You need to try and understand this moment.
Chris M. Thomasson
On 12 окт, 21:47, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > > > > Hmmm... what else then? "only because there is concurrent
> > > > > conflicting
> > > > > accesses to variable" Only because ...
> >
> > > > It's not an error by itself.
> > > Oh no, certainly not. How could it be?
> >
> > It was a simple volatile flag to shut down the program. Why should I use
> > a
> > condvar to do this? I mean, no data depended on the state of the flag,
> > so
> > what's wrong; exactly?
> I think that Szabolcs just don't understand what is "data depended on
> flag". Although it will be interesting to hear one more funny answer
> from him :)
Yeah. This is pretty "advanced" stuff we are dealing with here...
> > > > And how are you going to get access to that support? If not by
> > > > executing some instructions in some programming language? I am
> > > > curious. Are you going to pool some levers?
> > > You should learn some basic stuff, my young friend. You can get access
> > > to that support by looking up hardware implemented machine
> > > instructions for atomic access. One such an instruction is test-and-
> > > set (TAS) and another is check-and-swap (CAS). Without these you
> > > cannot do what you claim you can do.
> >
> > Your mistaken; sorry. Please check the following code implementing
> > Petersons
> > algorithm:
> >
> > http://groups.google.com/group/comp.programming.threads/browse_thread...
> >
> > Where are the atomic RMW instructions?
> There are no mutexes, there are no condition variables... let's see
> how Szabolcs will comment on algorithm which he is unable to
> understand :))
Well, humm... I am not sure if he understands or not. Apparently, from some
of his comments, well, I don't think he fully grasps the fact that the turn
variable does not need to be updated with atomic RMW instructions. I am not
sure he understands why a membar needs to be in there, or where to place it.
> It's already very funny, and it's going to become even more funny. I
> hope that Szabolcs will not retire :)))
;^D
Szabolcs Ferenczi
> > Namely you will have a visibility problem.
>
> Visibility problem; where?
Where you declared a volatile variable and you meant it as a shared
variable.
That does not work in case of multi-threaded programs. The volatile
keyword in C/C++ does not give you any guarantee that you will see the
change of that variable in anoher thread.
Be aware, it you pretend to be stupid for a long time, you will remain
so. Even if your masters pet you.
That is it, my young friend.
Best Regards,
Szabolcs
Dmitriy V'jukov
wrote:
> > > Namely you will have a visibility problem.
>
> > Visibility problem; where?
>
> Where you declared a volatile variable and you meant it as a shared
> variable.
>
> That does not work in case of multi-threaded programs. The volatile
> keyword in C/C++ does not give you any guarantee that you will see the
> change of that variable in anoher thread.
Do you ever hear term "cache-coherency"?
Please, also answer those messages:
http://groups.google.com/group/comp.programming.threads/tree/browse_frm/thread/66c05a4e857b98f2/329e43e62999b880?hl=en&rnum=21&_done=%2Fgroup%2Fcomp.programming.threads%2Fbrowse_frm%2Fthread%2F66c05a4e857b98f2%2F476e3a6371e7ed17%3Fhl%3Den%26#doc_329e43e62999b880
You are so funny!
Dmitriy V'jukov
Szabolcs Ferenczi
> On Oct 13, 9:00 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
> wrote:
>
> > > > Namely you will have a visibility problem.
>
> > > Visibility problem; where?
>
> > Where you declared a volatile variable and you meant it as a shared
> > variable.
>
> > That does not work in case of multi-threaded programs. The volatile
> > keyword in C/C++ does not give you any guarantee that you will see the
> > change of that variable in anoher thread.
>
> Do you ever hear term "cache-coherency"?
Yes, but it does not help you and it does not help your friend. The
volatile keyword cannot be used for shared variables in C/C++. Your
little pet has committed this error and your buggy tool could not
detect it.
That is the case my crazy friend who classifies data races into two
groups. One group contains the bad data races and these are the ones
that the Relacy tool happens to detect by accident. The other class is
classified as desirable data races, and this is the group that the
buggy Relacy tool fail to recognise.
> Please, also answer those messages:http://groups.google.com/group/comp.programming.threads/tree/browse_f...
Do not be so violent, my crazy friend. First you fix your broken race
detector code and then you can come back and report to me.
Best Regards,
Szabolcs
Chris M. Thomasson
On Oct 13, 7:15 pm, "Dmitriy V'jukov" <dvyu...@gmail.com> wrote:
> > On Oct 13, 9:00 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
> > wrote:
> >
> > > > > Namely you will have a visibility problem.
> >
> > > > Visibility problem; where?
> >
> > > Where you declared a volatile variable and you meant it as a shared
> > > variable.
> >
> > > That does not work in case of multi-threaded programs. The volatile
> > > keyword in C/C++ does not give you any guarantee that you will see the
> > > change of that variable in anoher thread.
Read here:
http://groups.google.com/group/comp.arch/browse_frm/thread/df6f520f7af13ea5
(REAL ALL!!!)
Yes. Cache-coherency does help in this scenario. I don't expect this code to
ever be run on a non-cc architecture. If it were run on a super-computer,
well, most of them have cache-coherent nodes, therefore I would bind the
threads to CPU's residing on the same cc node of course.
> > Do you ever hear term "cache-coherency"?
> Yes, but it does not help you and it does not help your friend. The
> volatile keyword cannot be used for shared variables in C/C++. Your
> little pet has committed this error and your buggy tool could not
> detect it.
I don't expect this code to be running on super-computer's which require
special instructions in order to make mutations visible to other nodes on
the system. Why do you think that the code should be production quality? I
mean, is a damn quick solution to a trivial academic problem. Its not that
important; really.
> That is the case my crazy friend who classifies data races into two
> groups. One group contains the bad data races and these are the ones
> that the Relacy tool happens to detect by accident. The other class is
> classified as desirable data races, and this is the group that the
> buggy Relacy tool fail to recognise.
You failed to recognize that I declared the `pg_run' variable as
`rl::atomic<bool> m_run' in the Relacy translation!
> > Please, also answer those >
> > messages:http://groups.google.com/group/comp.programming.threads/tree/browse_f...
> Do not be so violent, my crazy friend. First you fix your broken race
> detector code and then you can come back and report to me.
:^|
Szabolcs Ferenczi
> "Szabolcs Ferenczi" <szabolcs.feren...@gmail.com> wrote in message
>
> news:0db4a240-a92c-4f68...@f77g2000hsf.googlegroups.com...
> On Oct 13, 7:15 pm, "Dmitriy V'jukov" <dvyu...@gmail.com> wrote:
>
> > > On Oct 13, 9:00 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
> > > wrote:
>
> > > > > > Namely you will have a visibility problem.
>
> > > > > Visibility problem; where?
>
> > > > Where you declared a volatile variable and you meant it as a shared
> > > > variable.
>
> > > > That does not work in case of multi-threaded programs. The volatile
> > > > keyword in C/C++ does not give you any guarantee that you will see the
> > > > change of that variable in anoher thread.
>
> Read here:
>
> (REAL ALL!!!)
Read ONLY this but read it VERY, VERY CAREFULLY:
<quote from=
"http://groups.google.com/group/comp.programming.threads/msg/
360ea387df5c8409">
> The 'volatile' keyword only disables compiler optimizations.
I know.
> It does not disable CPU or hardware optimizations that are safe on
> single-threaded
> code.
Indeed.
</quote>
READ It MULTIPLE TIMES.
Besides, if you or your funny friends can provide any evidence that in
C/C++ the volatile keyword ensures the so-called visibility in multi-
threaded environment, which would justify your code, please let me
know about it.
Best Regards,
Szabolcs
Szabolcs Ferenczi
> "Szabolcs Ferenczi" <szabolcs.feren...@gmail.com> wrote in message
> > That is the case my crazy friend who classifies data races into two
> > groups. One group contains the bad data races and these are the ones
> > that the Relacy tool happens to detect by accident. The other class is
> > classified as desirable data races, and this is the group that the
> > buggy Relacy tool fail to recognise.
>
> You failed to recognize that I declared the `pg_run' variable as
> `rl::atomic<bool> m_run' in the Relacy translation!
Rather, I did recognise that you used `volatile' in your original
code.
static int volatile pg_run = 0;
So, are you saying that you were TRYING TO CHEAT when you wanted to
`prove' that your code is correct?
Best Regards,
Szabolcs
Dmitriy V'jukov
wrote:
> > Do you ever hear term "cache-coherency"?
>
> Yes, but it does not help you and it does not help your friend. The
> volatile keyword cannot be used for shared variables in C/C++. Your
> little pet has committed this error and your buggy tool could not
> detect it.
Relacy detects data-races. It is what it is intended for.
> That is the case my crazy friend who classifies data races into two
> groups. One group contains the bad data races and these are the ones
> that the Relacy tool happens to detect by accident. The other class is
> classified as desirable data races, and this is the group that the
> buggy Relacy tool fail to recognise.
Relacy detects all violations from rules which will become
International Organization for Standardization standard.
On what is your reasoning based? Is it some kind of standard? Or what?
> > Please, also answer those messages:http://groups.google.com/group/comp.programming.threads/tree/browse_f...
>
> Do not be so violent, my crazy friend. First you fix your broken race
> detector code and then you can come back and report to me.
Ok. It's fixed... Well, actually Relacy was detecting data-races for a
long time.
Now feel free to answer my questions.
Dmitriy V'jukov
Dmitriy V'jukov
wrote:
> Besides, if you or your funny friends can provide any evidence that in
> C/C++ the volatile keyword ensures the so-called visibility in multi-
> threaded environment, which would justify your code, please let me
> know about it.
No problem. Here is documentation on the most widespread C++ compiler:
(I'm not sure you can understand first part, but at least try to
understand last sentence)
"
Also, when optimizing, the compiler must maintain ordering among
references to volatile objects as well as references to other global
objects. In particular,
*
A write to a volatile object (volatile write) has Release
semantics; a reference to a global or static object that occurs before
a write to a volatile object in the instruction sequence will occur
before that volatile write in the compiled binary.
*
A read of a volatile object (volatile read) has Acquire
semantics; a reference to a global or static object that occurs after
a read of volatile memory in the instruction sequence will occur after
that volatile read in the compiled binary.
This allows volatile objects to be used for memory locks and releases
in multithreaded applications.
"
Dmitriy V'jukov
Dmitriy V'jukov
wrote:
Nope. You just confusing things one more time.
Dmitriy V'jukov
Szabolcs Ferenczi
> On 13 ÏËÔ, 21:27, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
> wrote:
> [...]
> > That is the case my crazy friend who classifies data races into two
> > groups. One group contains the bad data races and these are the ones
> > that the Relacy tool happens to detect by accident. The other class is
> > classified as desirable data races, and this is the group that the
> > buggy Relacy tool fail to recognise.
>
> Relacy detects all violations from rules which will become
> International Organization for Standardization standard.
> On what is your reasoning based? Is it some kind of standard? Or what?
Calm down my data race loving friend. Your little pet has just
admitted that he was cheating when he manipulated his code for your
tool.
Best Regards.
Szabolcs
Szabolcs Ferenczi
> > Do not be so violent, my crazy friend. First you fix your broken race
> > detector code and then you can come back and report to me.
>
> Ok. It's fixed...
You may prove it if you can.
Best Regards,
Szabolcs
Szabolcs Ferenczi
> On 13 ÏËÔ, 22:30, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
Hahaha. Yep. Escaping my friend? Your pet has cheated.
Best Regards,
Szabolcs
Szabolcs Ferenczi
> On 13 ÏËÔ, 22:24, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
Is that Visual C++ or is that the C++ standard? The former, I guess.
Besides, your friend committed the bug in plain C. He believes that
volatile in his C program means atomic. He will stay that ignorant if
you do not enlighten him.
Best Regards,
Szabolcs
Dmitriy V'jukov
wrote:
> > > > > That is the case my crazy friend who classifies data races into two
> > > > > groups. One group contains the bad data races and these are the ones
> > > > > that the Relacy tool happens to detect by accident. The other class is
> > > > > classified as desirable data races, and this is the group that the
> > > > > buggy Relacy tool fail to recognise.
>
> > > > You failed to recognize that I declared the `pg_run' variable as
> > > > `rl::atomic<bool> m_run' in the Relacy translation!
>
> > > Rather, I did recognise that you used `volatile' in your original
> > > code.
>
> > > static int volatile pg_run = 0;
>
> > > So, are you saying that you were TRYING TO CHEAT when you wanted to
> > > `prove' that your code is correct?
>
> > Nope. You just confusing things one more time.
>
> Hahaha. Yep. Escaping my friend? Your pet has cheated.
If you don't understand I can try to explain it to you in more simple
way.
C++'s volatile provides guarantee of real access to memory subsystem.
Cache-coherency provides guarantee of automatic distribution of that
access to all threads/processors.
This maps exactly to access to std::atomic<> object with
memory_order_relaxed memory ordering.
Key word here is "MAPS". I.e. programs expressed in different models,
so one has to map one model to another. You can't just mechanically
translate word by word from one model to another. You have to create
semantical mapping in order to preserve semantics... Although
personally you can... but you will get wrong results... as always.
Chris is smarter, he created correct semantical mapping... I think
it's just too difficult for you. Sorry.
Dmitriy V'jukov
Szabolcs Ferenczi
wrote:
Yep. Good guess. You only omitted the title of your copy paste text:
"Microsoft Specific"
http://msdn.microsoft.com/en-us/library/12a04hfd.aspx
Congratulations.
Dmitriy V'jukov
wrote:
Chris was not cheating. Sorry, Szabolcs, I think it's just too
difficult thing for you. Although I tried to explain it here:
http://groups.google.ru/group/comp.programming.threads/msg/9de268a39641b92d
Please tell whether you are able to understand such things or not.
Dmitriy V'jukov
Dmitriy V'jukov
wrote:
All necessary proofs are in source code. Source code is available. But
code is not very simple. If you are unable to understand it, you can
ask someone to explain it to you.
Dmitriy V'jukov
Szabolcs Ferenczi
> On 13 ÏËÔ, 23:31, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
Well, the key word here is mapping: He failed to preserve semantics.
He tried to cheat by `mapping' his C volatile type to atomic type in C+
+.
His C program is broken no matter how he cheats with the mapping.
That is the point, my data race loving friend.
Best Regards,
Szabolcs
Dmitriy V'jukov
wrote:
> > > > Besides, if you or your funny friends can provide any evidence that in
> > > > C/C++ the volatile keyword ensures the so-called visibility in multi-
> > > > threaded environment, which would justify your code, please let me
> > > > know about it.
>
> > > No problem. Here is documentation on the most widespread C++ compiler:
> > > (I'm not sure you can understand first part, but at least try to
> > > understand last sentence)
>
> > > "
> > > Also, when optimizing, the compiler must maintain ordering among
> > > references to volatile objects as well as references to other global
> > > objects. In particular,
>
> > > *
>
> > > A write to a volatile object (volatile write) has Release
> > > semantics; a reference to a global or static object that occurs before
> > > a write to a volatile object in the instruction sequence will occur
> > > before that volatile write in the compiled binary.
> > > *
>
> > > A read of a volatile object (volatile read) has Acquire
> > > semantics; a reference to a global or static object that occurs after
> > > a read of volatile memory in the instruction sequence will occur after
> > > that volatile read in the compiled binary.
>
> > > This allows volatile objects to be used for memory locks and releases
> > > in multithreaded applications.
> > > "
>
>
> > Is that Visual C++ or is that the C++ standard? The former, I guess.
>
> Yep. Good guess. You only omitted the title of your copy paste text:
>
> "Microsoft Specific"
>
> http://msdn.microsoft.com/en-us/library/12a04hfd.aspx
>
> Congratulations.
So what? People usually use some C/C++ *implementation*, not just C/C+
+. Do you see any problems here? I don't get you point.
Btw, mentioned semantics of volatile also cover C, not only C++.
Dmitriy V'jukov
Szabolcs Ferenczi
>
> Please tell whether you are able to understand such things or not.
I have answered your attempt to clean him from his cheating here:
http://groups.google.com/group/comp.programming.threads/msg/acb6ed0a8441860f
Best Regards,
Szabolcs
Szabolcs Ferenczi
> On 13 ÏËÔ, 23:27, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
> wrote:
>
> > On Oct 13, 9:14špm, "Dmitriy V'jukov" <dvyu...@gmail.com> wrote:
>
> > > > Do not be so violent, my crazy friend. First you fix your broken race
> > > > detector code and then you can come back and report to me.
>
> > > Ok. It's fixed...
>
> > You may prove it if you can.
>
> All necessary proofs are in source code. Source code is available. But
> code is not very simple. If you are unable to understand it, you can
> ask someone to explain it to you.
You may provide the diff.
So simple it would be if you were not cheating too (it seems that you
are very similar in trying to cheat), my data race loving friend.
Best Regards,
Szabolcs
Szabolcs Ferenczi
> On 13 ÏËÔ, 23:45, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
> wrote:
>
>
>
> > > > > Besides, if you or your funny friends can provide any evidence that in
> > > > > C/C++ the volatile keyword ensures the so-called visibility in multi-
> > > > > threaded environment, which would justify your code, please let me
> > > > > know about it.
>
> > > > No problem. Here is documentation on the most widespread C++ compiler:
> > > > (I'm not sure you can understand first part, but at least try to
> > > > understand last sentence)
>
> > > > "
> > > > references to volatile objects as well as references to other global
> > > > objects. In particular,
>
>
> > > > š š š A write to a volatile object (volatile write) has Release
> > > > semantics; a reference to a global or static object that occurs before
> > > > a write to a volatile object in the instruction sequence will occur
> > > > before that volatile write in the compiled binary.
>
> > > > š š š A read of a volatile object (volatile read) has Acquire
> > > > semantics; a reference to a global or static object that occurs after
> > > > a read of volatile memory in the instruction sequence will occur after
> > > > that volatile read in the compiled binary.
>
> > > > This allows volatile objects to be used for memory locks and releases
> > > > in multithreaded applications.
> > > > "
>
> > > Is that Visual C++ or is that the C++ standard? The former, I guess.
>
> > Yep. Good guess. You only omitted the title of your copy paste text:
>
> > "Microsoft Specific"
>
> >http://msdn.microsoft.com/en-us/library/12a04hfd.aspx
>
> > Congratulations.
>
> So what? People usually use some C/C++ *implementation*, not just C/C+
> +. Do you see any problems here? I don't get you point.
So that that your friend is hacking broken code. He has written a
plain C code but not a C++ one. Besides, he has just admitted in
another thread, cleaning the back part of his master, that it is not a
good idea to tailor the code to one platform.
> Btw, mentioned semantics of volatile also cover C, not only C++.
It only covers C compiled by the Visual C++ compiler, if it covers C
at all.
You like to hack non portable code, don't you?
Best Regards,
Szabolcs
Chris M. Thomasson
On Oct 13, 7:58 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > "Szabolcs Ferenczi" <szabolcs.feren...@gmail.com> wrote in message
> >
> > news:0db4a240-a92c-4f68...@f77g2000hsf.googlegroups.com...
> > On Oct 13, 7:15 pm, "Dmitriy V'jukov" <dvyu...@gmail.com> wrote:
> >
> > > > On Oct 13, 9:00 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
> > > > wrote:
> >
> > > > > > > Namely you will have a visibility problem.
> >
> > > > > > Visibility problem; where?
> >
> > > > > Where you declared a volatile variable and you meant it as a
> > > > > shared
> > > > > variable.
> >
> > > > > That does not work in case of multi-threaded programs. The
> > > > > volatile
> > > > > keyword in C/C++ does not give you any guarantee that you will see
> > > > > the
> > > > > change of that variable in anoher thread.
> >
> > Read here:
> >
> > http://groups.google.com/group/comp.arch/browse_frm/thread/df6f520f7a...
> > (REAL ALL!!!)
> Read ONLY this but read it VERY, VERY CAREFULLY:
You did not read the contents of the link above; typical. Also, you snipped
my post again without proper attribution. I am getting sick and tired of
that bullshi%.
> <quote from=
> "http://groups.google.com/group/comp.programming.threads/msg/
> 360ea387df5c8409">
> > The 'volatile' keyword only disables compiler optimizations.
> I know.
> > It does not disable CPU or hardware optimizations that are safe on
> > single-threaded
> > code.
> Indeed.
> </quote>
> READ It MULTIPLE TIMES.
> Besides, if you or your funny friends can provide any evidence that in
> C/C++ the volatile keyword ensures the so-called visibility in multi-
> threaded environment, which would justify your code, please let me
> know about it.
Listen, I don't have ANY state which depends on the state of the flag;
memory visibility is not a concern in this case! Anyway, the novelty of
conversing with you is wearing off fairly rapidly. Scum bags with attitudes
like yours used to get the shi% kicked out of them on a daily basis when
they went to elementary and/or high school. Oh well, to bad. On second
though, well, you probably deserved it; I hope you did not wear glasses back
then! Ouch. I would plonk your sorry as$, however, sometimes you make me
laugh out loud!
:^D
Chris M. Thomasson
Where did I say that the example code was 100% portable? If I did say that
somewhere, well, I was wrong. But I can't remember saying it.
Chris M. Thomasson
Try to make it break. Do you have access to any non-cc platforms? If you do,
then it will be easy. If you don't, well, its going to be fairly hard to do.
> That is the point, my data race loving friend.
innocuous data-races are HARMLESS! Why do you refuse to understand this?
Sometimes I think your head is filled with a bag of hammers.
Chris M. Thomasson
okay... Well, fine. I am WRONG, YOU ARE RIGHT! YOUR ALWAYS RIGHT! WEEEEE!
Now, would you please shut the hell up and fu%k off. I am done with this
bullsh% thread. You wasted way too much of my time. Rest in ignorance
as$hole.
Chris M. Thomasson
On Oct 12, 8:01 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> "Szabolcs Ferenczi" <szabolcs.feren...@gmail.com> wrote in message
> > > You seemingly experienced with some kind of error correction code but
> > > later on you just inserted an assert and left it behind as a dead
> > > code.
> > > void
> > > diner_sort_assert(
> > > diner* const _this
> > > ) {
> > > fork* const first = _this->forks[0];
> > > if (first > _this->forks[1]) {
> > > assert(first < _this->forks[1]);
> > > _this->forks[0] = _this->forks[1];
> > > _this->forks[1] = first;
> > > }
> > > }
> >
> > Actually, this `assert()' is useless because it will never trip. The
> > preceding if statement already ensures that the `assert()' will be pass.
> > I
> > don't exactly know why I put it in there.
> Well, the assert always fires if the preceding if statement selects
> the statement body but the code following the assert is dead.
Your are truly retarded.
> Well,
> you are not aware of it since you never have unit tests and you never
> care about the test coverage of your code.
> Obviously you were playing with fixing the "wrong" resource allocation
> and later on you rather asserted in that case but you have forgotten
> to remove the dead code.
Wrong. The `diner_sort_assert()' function works as-is. That's the way it was
when I first wrote this trivial example code and it and it has not changed
since.
> You know, once you start to grow a spaghetti
> code, you yourself cannot find your way in it.
Obviously you don't know what the hell your talking about. Don't tell me
what I was trying to do because you have absolutely no idea. BTW, don't even
bother replying, your dead to me wrt this thread.
Chris M. Thomasson
and moan! Re-download from:
http://webpages.charter.net/appcore/misc/diner_c.html
I make attempt to reduce chances of fat pig diners starving the innocent.
Oh, I use single writer, multi reader volatile variables! Sorry Szabolcs. Is
it portable? Na. I don't give a flying shi% wrt this trivial example code.
Enjoy!
:^D
Szabolcs Ferenczi
> I make some tweaks to the algorithm that ought to really make Szabolcs bitch
> and moan! Re-download from:
>
> http://webpages.charter.net/appcore/misc/diner_c.html
>
> I make attempt to reduce chances of fat pig diners starving the innocent.
FAILED ATTEMPT.
When I talk about STARVATION, I mean the terminus technicus in
concurrent programming. Can you look it up from some elementary study
book in concurrent programming or shall I give you a pointer to what
starvation means in multi-threaded environment?
So, your hack to give an extra logging info indicating that a
participant is refrained from eating but the participant goes on to
compete for the resources just proves that you does not understand the
standard terminology and you deserve a good basic course in concurrent
programming.
Besides, now you really drive your program into an endless loop with
this hack. It ends up in an endless `X Is Getting To Fat!' loop. Did
you run your hack at all?
> Oh, I use single writer, multi reader volatile variables!
struct global_s {
volatile unsigned long int eat_count[5];
};
You have the same problem here than you have with your other volatile
variable.
The volatile keyword just disables some compiler optimisations but
does not guarantee you any visibility for the variable in the other
threads.
In C/C++ the volatile keyword has nothing to do with multi-threading,
it has rather been introduced for memory mapped devices in embedded
software.
Whether you like it or not, in C/C++ you have to use external
libraries for handling the shared variables if you want to build
portable multi-threaded application. Well, the coming C++0x standard
will provide some very low level means for multi-threading.
Best Regards,
Szabolcs
Chris M. Thomasson
On Oct 14, 2:27 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > I make some tweaks to the algorithm that ought to really make Szabolcs
> > bitch
> > and moan! Re-download from:
> >
> > http://webpages.charter.net/appcore/misc/diner_c.html
> >
> > I make attempt to reduce chances of fat pig diners starving the
> > innocent.
> FAILED ATTEMPT.
[...]
:^D