Path: csiph.com!aioe.org!NBiuIU74OKL7NpIOsbuNjQ.user.gioia.aioe.org.POSTED!not-for-mail From: "Chris M. Thomasson" Newsgroups: comp.programming.threads,comp.lang.c++ Subject: Re: More precision about my new inventions of scalable algorithms.. Date: Fri, 19 Feb 2021 15:17:01 -0800 Organization: Aioe.org NNTP Server Lines: 19 Message-ID: References: NNTP-Posting-Host: NBiuIU74OKL7NpIOsbuNjQ.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: csiph.com comp.programming.threads:6325 comp.lang.c++:78477 On 2/19/2021 3:01 PM, Bonita Montero wrote: >>>> My below powerful inventions of LW_Fast_RWLockX and Fast_RWLockX >>>> that are two powerful scalable RWLocks that are FIFO fair > >>> RW-locks are never fair. > >> There are implementations that can be starvation free. > > No, impossible. Readers can hold the lock as long as they > want and starve out writers. And writers could do the same. Ummm... I am not sure what you mean here. The type of starvation I am talking about is when reader activity is so frequent that writers just can't seem to get in. Even if the reader critical sections are short. Every time a writer wants to get in, several readers jump in line. Its all about reader or writer priority, a lot of rwmutex impls have that flaw. Sure a reader can hold the lock for an hour, okay. Well, writers cannot get in for an hour. That's perfectly normal. This is not the same type of starvation I am referring to...