This is the mail archive of the
mailing list for the glibc project.
[RFC 0/1] Contributing a compound object to the libpthread
- From: Oleh Derevenko <oleh dot derevenko at gmail dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 14 Dec 2017 01:35:42 +0200
- Subject: [RFC 0/1] Contributing a compound object to the libpthread
- Authentication-results: sourceware.org; auth=none
On Wed, Jan 13, 2016 at 5:55 AM, Carlos O'Donell <firstname.lastname@example.org> 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:
> 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
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
“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.
-- Skype with underscore