Wednesday, May 11, 2016

Digest for comp.lang.c++@googlegroups.com - 14 updates in 7 topics

Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: May 11 11:47AM -0700

this donkey ram (male of the sheep or goat)
is very effective spammer not reading the answers - he is total brickass and also loonatic - this moron not only wastes its
own life in his downish and lunatic mission
(producing very boring crao very slowly, im sure next five years he will be turning the same boring crap)
but can get down whole groups, still staying absolutely downish and unpunishable.. sometimes he uses a new thread to spread over a usenet that he is 'celine dijon' listener and want you to listen this 'beautifull music'.. it is very sad case of abusing brickass
 
Some news serwer owners (or whhat it is should just block this brickass (for abusing the usenet especially massively),
or come court should warn him and if not listening should sentence him to pay penalty (i may accept this summ as i get a lot of work clicking hiding this trash, so ram prepare to pay a round amount of money), without it you could ignore our brickass (which needs a bit of work but is obtainable, sadly all newcomers will still be scarred by this trash), or laugh at this ram in hope that it will buiild the anti-brickass defence system ;-) agains stupidity.. This is a weird situation when agressor is unpunishable, wreaks havoc and nobody can do nothing it that (unles treating his down syndrome as
a punishment perself) weird situation
Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: May 11 12:12PM -0700

W dniu środa, 11 maja 2016 20:48:09 UTC+2 użytkownik Prroffessorr Fir Kenobi napisał:
 
> Some news serwer owners (or whhat it is should just block this brickass (for abusing the usenet especially massively),
> or come court should warn him and if not listening should sentence him to pay penalty (i may accept this summ as i get a lot of work clicking hiding this trash, so ram prepare to pay a round amount of money), without it you could ignore our brickass (which needs a bit of work but is obtainable, sadly all newcomers will still be scarred by this trash), or laugh at this ram in hope that it will buiild the anti-brickass defence system ;-) agains stupidity.. This is a weird situation when agressor is unpunishable, wreaks havoc and nobody can do nothing it that (unles treating his down syndrome as
> a punishment perself) weird situation
 
I am close to cast a curse on this pest (not sayin that this will work, im jokin a bit) but that would be not ethical..
 
but the case of this brickass agression
is somewhat serious.. usenet being virtual is partially a world of nowledge/scholarly
so such kind of abusers are some crime in this word that makeit also serious.. so donkey brickass dont feel to safe even if you play lunatic so hard ..
 
(one day maybe i will analyse it more and wrote some text on it, now i got enough of lunatic brickasses for this time)
Ian Collins <ian-news@hotmail.com>: May 12 08:18AM +1200

On 05/12/16 12:56 AM, Jerry Stuckle wrote:
 
>> Please don't respond to Ramine spam decent news servers filter out. It
>> never engages in a discussion, so replying merely defeats the spam filters.
 
> And how has ignoring helped? Has it stopped him from posting?
 
No and nether has responding which is why news servers consider it to be
spam.
 
> Just because YOU don't see his posts doesn't mean everyone else doesn't.
 
No one using decent servers such as news.Individual.net and
news.aioe.org see its postings, just the pointless replies.
 
--
Ian Collins
jt@toerring.de (Jens Thoms Toerring): May 11 10:13PM


> > Just because YOU don't see his posts doesn't mean everyone else doesn't.
 
> No one using decent servers such as news.Individual.net and
> news.aioe.org see its postings, just the pointless replies.
 
Or, if you're not on a decent server, your killfile will
do the job of making this idiot invisible nicely (unless
he, again, changes his "From:" field, but that doesn't
seem to happen too often). I've got 4 entries for him
in my killfile:
 
aminer@videotron.ca
aminer@toto.net
ramine@1.1
aminer68@gmail.com
 
Feel free to use them;-)
Best regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
bleachbot <bleachbot@httrack.com>: May 11 03:18PM +0200

bleachbot <bleachbot@httrack.com>: May 11 03:20PM +0200

bleachbot <bleachbot@httrack.com>: May 11 03:30PM +0200

bleachbot <bleachbot@httrack.com>: May 11 04:14PM +0200

bleachbot <bleachbot@httrack.com>: May 11 05:18PM +0200

Ramine <ramine@1.1>: May 11 08:18AM -0700

Hello....
 
 
I have benchmarked my new algorithm of my scalable Asym_DRWLock
that is a scalable Asymmetric Distributed reader-writer mutex, against
scalable DRWLock that is a scalable Distributed Reader-Writer Mutex,
and scalable Asym_DRWLock is 1.60 time faster than scalable DRWLock.
 
So hope that you will love my great C++ synchronization objects library..
 
 
You can download it from:
 
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 11 07:15AM -0700

Hello,
 
 
Hope you have read my previous post..
 
But look now at the source code of my SeqlockX algorithm here:
 
https://sites.google.com/site/aminer68/scalable-seqlockx
 
There is a load on x86 on the reader side section of my SeqlockX
algorithm like this:
 
myid2:=FCount4^.fcount4;
 
 
This is why it works , because loads and stores on x86 are
not reordered with this load above, so it permit my SeqlockX to
not use any atomics or fences on the the reader side.
 
So i think that's not possible with this Asymmetric rw_mutex from Dmitry
Vyukov as i have explained before:
 
https://groups.google.com/forum/#!topic/lock-free/Hv3GUlccYTc
 
 
And i think that's not possible with my scalable Asymmetric
Distributed reader-writer mutex, because it needs an x86 fence
on the reader side of the critical section.
 
So if you need a costless sychronization mechanism on the reader side
that elminates livelock when there is more writers, use my
SelqockX implementation of my algorithm.
 
 
Hope you have understood what i mean.
 
 
You can download my great and updated C++ synchronization objects
library from:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 11 09:30AM -0700

Hello......
 
Look at this scalable Asymmetric rw_mutex from Dmitry Vyukov:
 
https://groups.google.com/forum/#!topic/lock-free/Hv3GUlccYTc
 
 
If you have noticed he is using a compiler "_ReadWriteBarrier()",
but this doesn't emmit a fence on x86, it is just a compiler barrier,
but i am wondering how can he do it this way because loads
of the reader critical section can be reordered on x86 with the
following store:
 
reader_inside[current_thread_index] = true;
 
 
So i think it is a bug, can you please shade some light on this ?
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 11 09:21AM -0700

Hello...
 
Look at this scalable Asymmetric rw_mutex from Dmitry Vyukov:
 
https://groups.google.com/forum/#!topic/lock-free/Hv3GUlccYTc
 
 
If you have noticed he is using a compiler "_ReadWriteBarrier()",
but this doesn't emmit a fence on x86, it is just a compiler barrier,
but i am wondering how can he do it this way because loads
of the reader critical section are reordered with the following store:
 
reader_inside[current_thread_index] = true;
 
 
So i think it is a bug, can you please share a light on this ?
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 11 09:18AM -0700

Hello,
 
Look at this scalable Asymmetric rw_mux from Dmitry Vyukov:
 
https://groups.google.com/forum/#!topic/lock-free/Hv3GUlccYTc
 
 
If you have noticed he is using a compiler "_ReadWriteBarrier()",
but this doesn't emmit a fence on x86, it is just a compiler barrier,
but i am wondering how can he do it this way because loads
of the reader critical section are reordered with the following store:
 
reader_inside[current_thread_index] = true;
 
 
So i think it is a bug, can you please share a light on this ?
 
 
 
Thank you,
Amine Moulay Ramdane.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)