[libvirt] [RFC] Atomic Operations

[Martin Kletzander]

On Wed, Jun 04, 2014 at 08:16:16AM -0400, Tucker DiNapoli wrote:
>I'm working on job control which involves a lot of locking and unlocking,
>often for operations that could be done atomically. I use the existing
>atomic integer operations in viratomic.h where possible, but there are a
>lot of parameters involved in jobs (such as time, thread id's, progress
>information, etc) which don't fit in an integer.
>

Anything for which you need to implement such operations, you can also
create some lock for that.  If there's an object (struct) you want to
have those operations on, the cleanest way (for libvirt code) is to
create a "class" that derives from virObjectLockable.  That way you
can use virObjectLock/Unlock operations on that object.  Each
operation on that object should be in a function anyway, so the places
for doing lock/unlock should be clear.  Using viratomic is definitely
faster, but, as you said, we don't use that for anything else than
integers.

>I have several ideas of ways to update the existing integer atomic
>operations to support more types. The easiest way (at least regarding code)
>would be to use an existing atomic operations library. My suggestion would
>be the libatomic_ops library, which is licensed under an MIT style license
>and could be added to the source tree as a git submodule (similar to the
>way gnulib is) or a specific version could be used and the library source
>itself added to the git repository. The library can be found at
>https://github.com/ivmai/libatomic_ops/ .
>

I don't know how others will respond, but I myself would avoid adding
new dependencies unless completely necessary.  But let's see what
others think.  If we have enough use cases for that it could speed up
some core bottlenecks maybe.

>The other way of augmenting atomic operations would be to extend the
>existing viratomic.h file to support additional types. Personally I have
>experience working with GCC atomic operations and could implement that
>myself, but I wouldn't be able to implement the windows versions.
>
>Again I think the easiest and most maintainable way of supporting atomic
>operations is via an external library, but I am not sure of the feasibility
>of adding another dependency to libvirt. In general atomic operations are
>an optimization, but they can help make multithreaded programming easier
>and I think libvirt would be enhanced by having more comprehensive support
>for atomic operations.
>
>Tucker DiNapoli
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140604/968bb4c2/attachment-0001.sig>