Re: [RFC 0/1] Contributing a compound object to the libpthread

[Oleh Derevenko <oleh.derevenko@gmail.com>]

Hi All,

Well guys, really! This is a cool thing!
With a mutex wheel a master thread can wait for a slave thread to
complete an operation (the slave thread "signals" after the
completion). And with yet an additional mutex, the slave thread can
know that the master thread has finished waiting for the signal (this
may be needed to make sure that the shared synchronization objects are
safe to be reused/deleted and that the threads do not reference each
other anymore). And all this — with full priority inheritance. This is
a kind of "provider-consumer" problem with event-like synchronization
objects (e.g. condvars) completely eliminated.

Oleh Derevenko
-- Skype with underscore


On Thu, Dec 14, 2017 at 1:35 AM, Oleh Derevenko
<oleh.derevenko@gmail.com> wrote:
> Hi Carlos,
>
> On Wed, Jan 13, 2016 at 5:55 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>>
>> On 01/06/2016 06:38 AM, Oleh Derevenko wrote:
>> > Hi All,
>> >
>> > Sorry for a somewhat unusual question.
>> >
>> > I have a devised a compound synchronization object approximately of
>> > the rwlock's level which helps with some aspects of data queue
>> > handling and provider-consumer interactions between threads. One of
>> > particular uses - it allows to wait for a worker to complete a
>> > specific work item with priority inheritance from the waiting thread
>> > (if the OS provides the priority inheritance feature at all, of
>> > course). If I would like to contribute this object to the libpthread,
>> > what would be the best way/place to do it?
>>
>> At present libpthread implements the POSIX Threads functions and some
>> additional non-portable extenions. We don't deviate much from pthreads.
>> If your new feature is quite different then it might not be a match for
>> libpthread or glibc.
>>
>> You should start by making your code available perhaps in a distinct
>> project or as a glibc add-on and discussing further once you have more
>> concrete information to present. Consider carefully the license of your
>> code and all things you'll need for a good contribution:
>> https://sourceware.org/glibc/wiki/Contribution%20checklist
>>
>> I know it's quite a lot to review, but license and copyright assignment
>> are the top two things to get out of the way if you're looking to
>> contribute to the project at any level.
>>
>> We are also starting to discuss a non-pthread experimental library
>> for exposing executaion agent interfaces to be used by higher level
>> frameworks whose requirements don't directly map well onto POSIX
>> threads. Your synchronization object might be suited to such an
>> experimental library, but again it's hard to say without any more
>> information.
>>
>> Cheers,
>> Carlos.
>>
>
> Sorry for a kind of necroposting -- it has been quite long since I
> started this topic.
> So, having considered what I had, I decided to apply for a patent on
> the synchronization technique I mentioned. After all, it's not every
> day you come up with ideas like that.
> Now the application has been published and is available at
> http://appft.uspto.gov/netahtml/PTO/search-adv.html (use
> “DN/20170329652” for the search) and thus I can present the related
> implementation here, following in the next e-mail fragment. The
> functions and the synchronization objects themselves were formatted in
> the style and with naming conventions of libpthread (merely for sake
> of convenience). There are descriptive commentaries in the code and a
> few usage examples written as C pseudocode in a commentary at the end
> of the header file.
> I could provide these objects free for GPL licensed projects (and
> probably for LGPL applications as well -- all, but libraries, to avoid
> misuse within commercial sotware), if the public is interested in it.
> I'm not generally following the discussions here but throwing a quick
> glance now and then I saw people trying to get priority inheritance
> with pthread_cond_wait(). My synchronization objects are a readily
> available alternative. And though requiring somewhat advanced
> synchronization skills and proper thread hierarchy design, they cover
> all my needs for event waits requiring priority inheritance.
>
> --
>
> Oleh Derevenko
>  -- Skype with underscore