similar to: [LLVMdev] Code/comment seems not synchronized in Mutex.cpp and RWMutex.cpp

On Fri, Jan 13, 2012 at 11:58 PM, Chris Lattner <clattner at apple.com> wrote: > On Jan 13, 2012, at 11:17 PM, David Blaikie wrote: > >>> On some (linux?) implementations, various pthread APIs are defined as "weak extern" symbols in libc and strong definitions in libpthreads.  The idea of this check is thus to detect if pthreads is linked into the app and enable

On Jan 13, 2012, at 11:17 PM, David Blaikie wrote: >> On some (linux?) implementations, various pthread APIs are defined as "weak extern" symbols in libc and strong definitions in libpthreads. The idea of this check is thus to detect if pthreads is linked into the app and enable threads if so. > > Sorry, right - I should've been more clear. I understand that that's

On Fri, Jan 13, 2012 at 10:24 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 13, 2012, at 4:43 PM, David Blaikie wrote: > >> It looks like for a while now (5 years) some code that was meant to do >> smart things in Mutex.cpp hasn't been doing such smart things: >> >>

# HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1326564288 -3600 # Node ID 259112aee618753552056e398f940d1fd9fcc6f7 # Parent f581bb82fecd51e8fbd9c2e4ae9e76b08a695587 libxl: fix mutex initialization The macro PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is not defined on NetBSD, so define mutex attributes manually. Changes since v1: * Fix leak of mutex attr.

On Jan 13, 2012, at 4:43 PM, David Blaikie wrote: > It looks like for a while now (5 years) some code that was meant to do > smart things in Mutex.cpp hasn't been doing such smart things: > > https://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Support/Mutex.cpp?r1=29287&r2=29932&diff_format=h > > I don't know if this change was even deliberate since it came in

Hi, The old llvm::sys::RWMutex use platform-specific lock mechanism to implement read/write lock. For example, SRWLock on Windows and pthread read/write lock on *nix systems. However, in comparison with the approach that implement read/write lock base on std::atomic, the old methods not only has potential performance issue(Sorry I can't provide concrete evidence, any benchmark result is

It looks like for a while now (5 years) some code that was meant to do smart things in Mutex.cpp hasn't been doing such smart things: https://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Support/Mutex.cpp?r1=29287&r2=29932&diff_format=h I don't know if this change was even deliberate since it came in with another change & the description doesn't mention it. Should we do

Hi Jeremy,   I got some info on that topic from the illumos devs:   > It's a sporadic issue, you're lucky enough to not encounter it on 4.9.5. > > I confirmed in 4.10.2, it happens: > > winbindd.log:  tdb(/tmw-nas-3p/samba/var/lock/gencache.tdb): tdb_open_ex: tdb_mutex_init failed for /tmw-nas-3p/samba/var/lock/gencache.tdb: Device busy > > So either apply OS fix, or

In preparation for parallel processing, we need to be sure that two threads belonging to the same connection cannot interleave their I/O except at message boundaries. Add a mutex around all reads and writes that must occur as a group (for now, there is no contention for either mutex). Signed-off-by: Eric Blake <eblake@redhat.com> --- src/connections.c | 27 +++++++++++++++++++++++++-- 1

On Thu, Nov 16, 2017 at 09:26:54PM -0600, Eric Blake wrote: > In preparation for parallel processing, we need to be sure that > two threads belonging to the same connection cannot interleave > their I/O except at message boundaries. Add a mutex around > all reads and writes that must occur as a group (for now, there > is no contention for either mutex). > > Signed-off-by:

Hi, I am just letting you know that I have not been able to build LLVM using CMake since I ran svn up yesterday. And it would be great if somebody could tell me whether the problem is on my end. What I did was, ~/llvm$ svn up ~/llvm$ mkdir cmakebuild ~/llvm$ cd cmakebuild ~/llvm/cmakebuild$ cmake -DCMAKE_BUILD_TYPE:STRING="Release" -DLLVM_TARGETS_TO_BUILD:STRING="X86" ..

Hello, I downloaded LLVM 2.6 and was attempting to compile it with TDM-GCC 4.4.1-tdm2-sjlj + cmake 2.6.4 and this happened: =============Console=================== C:\projects\game-editor\LLVM\build-root>mingw32-make [ 2%] Built target LLVMSystem [ 5%] Built target LLVMSupport [ 7%] Built target tblgen [ 7%] Built target intrinsics_gen [ 10%] Built target LLVMCore [ 12%] Built target

This is a patch based on Krishna Kumar's patch series which implements multiple VQ support for virtio-net. The patch was tested with ver3 of the patch. Cc: Krishna Kumar <krkumar2 at in.ibm.com> Cc: Michael S. Tsirkin <mst at redhat.com> Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: virtualization at lists.linux-foundation.org Cc: netdev at vger.kernel.org Signed-off-by:

This is a patch based on Krishna Kumar's patch series which implements multiple VQ support for virtio-net. The patch was tested with ver3 of the patch. Cc: Krishna Kumar <krkumar2 at in.ibm.com> Cc: Michael S. Tsirkin <mst at redhat.com> Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: virtualization at lists.linux-foundation.org Cc: netdev at vger.kernel.org Signed-off-by:

As many of you know, OpenSSH 3.7.X, unlike previous versions, makes PAM authentication take place in a separate process or thread (launched from sshpam_init_ctx() in auth-pam.c). By default (if you don't define USE_POSIX_THREADS) the code "fork"s a separate process. Or if you define USE_POSIX_THREADS it will create a new thread (a second one, in addition to the primary thread). The

Hi all! I do not know openssh patch policy so I am just sending the patch to the mailing list. Sorry for inconvenience. Ssh-agent seems to be too slow if you need to access thousands of servers. This is a simple patch to enable threading in ssh2 authentication. Patch adds "-p numthreads" option and defaults to the number of processors. I've tested it as I could, but

Ok. I hand-modified the linux-flashplugin6 shared library to remove all of the DT_NEEDED entries. I then modified flashpluginwrapper to add the following functions: void __assert_fail(const char *assertion, const char *file, unsigned int line, const char *function) { fprint (stderr, "%s:%d:%s: %s\n", file, line, function, assertion); abort (); } #include <ctype.h>

Although we haven't always checked that pthread_mutex_[un]lock succeeded, it never hurts to avoid blatant programming bugs such as when EINVAL can detect use of an uninitialized mutex. Signed-off-by: Eric Blake <eblake@redhat.com> --- Applies on top of my series to move cleanup.c to common/ Should I also go through and add checking to other bare pthread_mutex_[un]lock() calls?

Jon Harrop wrote: > Having implemented a GC for HLVM, I am now turning my attention to > implementing a GC that supports parallelism. To do this, I would like to use > atomic instructions as well as mutexes. What is the status of LLVM's atomic > instrinsics (e.g. CAS)? Is anyone using them in real projects? > > I realised that an obvious test would be to compile some

--- filters/delay/nbdkit-delay-filter.pod | 4 +- filters/rate/nbdkit-rate-filter.pod | 84 +++++++++ configure.ac | 2 + filters/rate/bucket.h | 62 +++++++ filters/rate/bucket.c | 173 +++++++++++++++++++ filters/rate/rate.c | 235 ++++++++++++++++++++++++++ TODO | 9 +