comp.programming.threads

• Date Index

---

• Strong competition resolving between threads, Dmitriy Vyukov
  • Re: Strong competition resolving between threads, remi.chateauneu@xxxxxxxxx
    • Re: Strong competition resolving between threads, Dmitriy Vyukov
      • Re: Strong competition resolving between threads, Dmitriy Vyukov
• Naming pthreads??, Vinay
  • Re: Naming pthreads??, Ivan Wang
• Max number of threads that can be used?, Sonny
  • Re: Max number of threads that can be used?, Ian Collins
  • Re: Max number of threads that can be used?, Torsten Robitzki
    • Re: Max number of threads that can be used?, Sonny
      • Re: Max number of threads that can be used?, Torsten Robitzki
      • Re: Max number of threads that can be used?, Sonny
      • Re: Max number of threads that can be used?, Torsten Robitzki
      • Re: Max number of threads that can be used?, Sonny
      • Re: Max number of threads that can be used?, Torsten Robitzki
      • Re: Max number of threads that can be used?, Sonny
      • Re: Max number of threads that can be used?, Torsten Robitzki
      • Message not available
      • Re: Max number of threads that can be used?, Markus Elfring
      • Re: Max number of threads that can be used?, David Schwartz
      • Re: Max number of threads that can be used?, Sonny
      • Re: Max number of threads that can be used?, Markus Elfring
      • Re: server design check, Markus Elfring
  • Re: Max number of threads that can be used?, Markus Elfring
  • Re: Max number of threads that can be used?, llothar
    • Re: Max number of threads that can be used?, Chris Thomasson
    • Re: Max number of threads that can be used?, Chris Friesen
      • Re: Max number of threads that can be used?, Ian Collins
• ABP stealing deque algorithm, Dmitriy Vyukov
• debugging c program, John Hanley
  • Re: debugging c program, David Schwartz
    • Re: debugging c program, Joel Yliluoma
• Re: transactional memory hype!, John Dallman
  • <Possible follow-ups>
  • Re: transactional memory hype!, John Dallman
• mutex lock error, pthreads
  • Re: mutex lock error, pthreads
  • Re: mutex lock error, David Schwartz
    • Re: mutex lock error, pthreads
• Debugging Multi-core Processors., srimks11@xxxxxxxxx
  • Re: Debugging Multi-core Processors., John Dallman
• terminating blocked thread, Ulrich Eckhardt
  • Re: terminating blocked thread, Gianni Mariani
  • Re: terminating blocked thread, Chris Vine
  • Re: terminating blocked thread, Maxim Yegorushkin
• thread synchronization of flag, Denise Kleingeist
  • Re: thread synchronization of flag, Gianni Mariani
    • Re: thread synchronization of flag, Denise Kleingeist
      • Re: thread synchronization of flag, Gianni Mariani
      • Re: thread synchronization of flag, David Schwartz
      • Re: thread synchronization of flag, Gianni Mariani
      • Re: thread synchronization of flag, David Schwartz
      • Re: thread synchronization of flag, Gianni Mariani
  • Re: thread synchronization of flag, David Schwartz
    • Re: thread synchronization of flag, Denise Kleingeist
      • Re: thread synchronization of flag, David Schwartz
      • Re: thread synchronization of flag, llothar
      • Re: thread synchronization of flag, blytkerchan
      • Re: thread synchronization of flag, David Schwartz
  • Re: thread synchronization of flag, blytkerchan
    • Re: thread synchronization of flag, Denise Kleingeist
      • Re: thread synchronization of flag, blytkerchan
      • Re: thread synchronization of flag, Chris Thomasson
      • Re: thread synchronization of flag, blytkerchan
    • Re: thread synchronization of flag, David Schwartz
  • Re: thread synchronization of flag, Markus Elfring
    • Re: thread synchronization of flag, Denise Kleingeist
      • Re: thread synchronization of flag, Markus Elfring
  • Re: thread synchronization of flag, Chris Thomasson
    • Re: thread synchronization of flag, Denise Kleingeist
      • Re: thread synchronization of flag, Chris Thomasson
  • Re: thread synchronization of flag, Maxim Yegorushkin
    • Re: thread synchronization of flag, Chris Thomasson
      • Re: thread synchronization of flag, Gianni Mariani
      • Re: thread synchronization of flag, Chris Thomasson
      • Re: thread synchronization of flag, Chris Thomasson
• large proportion of runtime spent in linux kernel, Naveen Parihar
  • Re: large proportion of runtime spent in linux kernel, Igmar Palsenberg
  • Re: large proportion of runtime spent in linux kernel, Chris Friesen
    • Re: large proportion of runtime spent in linux kernel, Tom Horsley
    • Re: large proportion of runtime spent in linux kernel, Naveen Parihar
• question regarding the userlevel and kernel level thread., pshebbar
  • Re: question regarding the userlevel and kernel level thread., pshebbar
  • Re: question regarding the userlevel and kernel level thread., Maxim Yegorushkin
• Is it possible for Google to create a feature where you can view different time periods using Google earth?, retinchet2
• A Robust POSIX Condition Variable Technique., Chris Thomasson
  • Re: A Robust POSIX Condition Variable Technique., Chris Thomasson
  • Re: A Robust POSIX Condition Variable Technique., Chris Thomasson
  • Re: A Robust POSIX Condition Variable Technique., Chris Thomasson
    • Re: A Robust POSIX Condition Variable Technique., Ian Collins
      • Re: A Robust POSIX Condition Variable Technique., Chris Thomasson
      • Re: A Robust POSIX Condition Variable Technique., Chris Thomasson
• Terminate Child thread, Ani
  • Re: Terminate Child thread, Marcel Müller
  • Re: Terminate Child thread, David Schwartz
• sem_open takes semaphore?, Mike - EMAIL IGNORED
  • Re: sem_open takes semaphore?, Frank Cusack
    • Re: sem_open takes semaphore?, Mike - EMAIL IGNORED
      • Re: sem_open takes semaphore?, Frank Cusack
      • Re: sem_open takes semaphore?, Mike - EMAIL IGNORED
      • Re: sem_open takes semaphore?, Frank Cusack
      • Re: sem_open takes semaphore?, Mike - EMAIL IGNORED
      • Re: sem_open takes semaphore?, Frank Cusack
      • Re: sem_open takes semaphore?, Mike - EMAIL IGNORED
      • Re: sem_open takes semaphore?, Frank Cusack
      • Re: sem_open takes semaphore?, Mike - EMAIL IGNORED
      • Re: sem_open takes semaphore?, Frank Cusack
      • Re: sem_open takes semaphore?, Steve Watt
      • Re: sem_open takes semaphore?, Mike - EMAIL IGNORED
      • Re: sem_open takes semaphore?, Steve Watt
• Computer programmings, shaw
• Re: Multi Threading and portability issues, Sergey Nikulov
  • Re: Multi Threading and portability issues, Colin Paul Gloster
• handling static variables in parallel code, Naveen Parihar
  • Re: handling static variables in parallel code, blytkerchan
  • Re: handling static variables in parallel code, Torsten Robitzki
  • Re: handling static variables in parallel code, Steve Watt
    • Re: handling static variables in parallel code, Naveen Parihar
      • Re: handling static variables in parallel code, blytkerchan
• Signals and Posix Threads, Mike - EMAIL IGNORED
  • Re: Signals and Posix Threads, Pierre Asselin
  • Re: Signals and Posix Threads, Frank Cusack
    • Re: Signals and Posix Threads, Mike - EMAIL IGNORED
  • Re: Signals and Posix Threads, Gianni Mariani
• [Q] POSIX thread debugging with gdb, Kihyeok Kim
  • Re: [Q] POSIX thread debugging with gdb, Joe Seigh
    • Re: [Q] POSIX thread debugging with gdb, Chris Thomasson
  • Re: POSIX thread debugging with gdb, Szabolcs Ferenczi
• Dual processor How To's ?Different question, sandy
  • Re: Dual processor How To's ?Different question, John Dallman
    • Re: Dual processor How To's ?Different question, sandy
      • Re: Dual processor How To's ?Different question, John Dallman
      • Re: Dual processor How To's ?Different question, David Schwartz
      • Re: Dual processor How To's ?Different question, sandy
      • Re: Dual processor How To's ?Different question, David Schwartz
  • Re: Dual processor How To's ?Different question, David Schwartz
    • Re: Dual processor How To's ?Different question, sandy
      • Re: Dual processor How To's ?Different question, David Schwartz
• Thread application dumping on RHAS 4, Vishu
  • Re: Thread application dumping on RHAS 4, arun.darra@xxxxxxxxx
    • Re: Thread application dumping on RHAS 4, Paul Pluzhnikov
      • Re: Thread application dumping on RHAS 4, Vishu
      • Re: Thread application dumping on RHAS 4, Paul Pluzhnikov
      • Re: Thread application dumping on RHAS 4, Vishu
      • Re: Thread application dumping on RHAS 4, Paul Pluzhnikov
• Hyper Terminal Problem, Adarsh Patel
  • Re: Hyper Terminal Problem, Ian Collins
• Smart pointer and thread, Jack
  • Re: Smart pointer and thread, Ian Collins
  • Re: Smart pointer and thread, Torsten Robitzki
• Re: lock-free; are you using it?, Chris Thomasson
  • <Possible follow-ups>
  • Re: lock-free; are you using it?, Colin Paul Gloster
    • Re: lock-free; are you using it?, blytkerchan
  • Re: lock-free; are you using it?, Colin Paul Gloster
    • Re: lock-free; are you using it?, blytkerchan
  • Re: lock-free; are you using it?, dicksters@xxxxxxxxxxxxxx
    • Re: lock-free; are you using it?, Chris Thomasson
      • Re: lock-free; are you using it?, Chris Thomasson
• Re: Asymmetric Dekker Synchronization, Chris Thomasson
• Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), David Schwartz
  • Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), Jason Roscoe
    • Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), Chris Thomasson
      • Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), Jason Roscoe
      • Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), Bert . Wesarg
      • Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), Jason Roscoe
      • Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), Bert . Wesarg
      • Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), David Schwartz
      • Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), Jason Roscoe
      • Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), David Schwartz
      • Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), David Schwartz
      • Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), Markus Elfring
    • Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), David Schwartz
      • Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), Chris Thomasson
      • Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), Martin Vuille
      • Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), Jason Roscoe
    • Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), Steve Watt
      • Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), Dave Butenhof
  • <Possible follow-ups>
  • Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), Dave Butenhof
    • Re: EPERM from pthread_mutex_unlock after fork using pthread_atfork(), Jason Roscoe
• pthread_cancel + sleep + pthread_cleanup_push, leandro.costa@xxxxxxxxx
  • Re: pthread_cancel + sleep + pthread_cleanup_push, leandro.costa@xxxxxxxxx
    • Re: pthread_cancel + sleep + pthread_cleanup_push, leandro.costa@xxxxxxxxx
• Re: "Intel open sources multicore programming tool"", remi.chateauneu@xxxxxxxxx
  • <Possible follow-ups>
  • Re: "Intel open sources multicore programming tool"", Chris Thomasson
    • Re: "Intel open sources multicore programming tool"", Ben Pfaff
• cmpxchg16b, gcc, AMD machines, Alex Ma
  • Re: cmpxchg16b, gcc, AMD machines, Zeljko Vrba
    • Re: cmpxchg16b, gcc, AMD machines, Alex Ma
      • Re: cmpxchg16b, gcc, AMD machines, Chris Thomasson
      • Re: cmpxchg16b, gcc, AMD machines, Alex Ma
      • Re: cmpxchg16b, gcc, AMD machines, Chris Thomasson
      • Re: cmpxchg16b, gcc, AMD machines, Chris Thomasson
      • Re: cmpxchg16b, gcc, AMD machines, Alex Ma
      • Re: cmpxchg16b, gcc, AMD machines, Chris Thomasson
      • Re: cmpxchg16b, gcc, AMD machines, Chris Thomasson
      • Re: cmpxchg16b, gcc, AMD machines, Chris Thomasson
      • Re: cmpxchg16b, gcc, AMD machines, Zeljko Vrba
      • Re: cmpxchg16b, gcc, AMD machines, Zeljko Vrba
      • Re: cmpxchg16b, gcc, AMD machines, Chris Thomasson
      • Re: cmpxchg16b, gcc, AMD machinesz, Alex Ma
      • Re: cmpxchg16b, gcc, AMD machinesz, Chris Thomasson
• Re: multi-threading support by script languages, Markus Elfring
• Re: C++: PTHREAD_CANCEL_ASYNCHRONOUS and random crash, Joel Yliluoma
  • Re: C++: PTHREAD_CANCEL_ASYNCHRONOUS and random crash, Torsten Robitzki
  • Re: C++: PTHREAD_CANCEL_ASYNCHRONOUS and random crash, Ian Collins
    • Re: C++: PTHREAD_CANCEL_ASYNCHRONOUS and random crash, Joel Yliluoma
      • Re: C++: PTHREAD_CANCEL_ASYNCHRONOUS and random crash, Joel Yliluoma
      • Re: C++: PTHREAD_CANCEL_ASYNCHRONOUS and random crash, Ian Collins
  • Re: C++: PTHREAD_CANCEL_ASYNCHRONOUS and random crash, David Schwartz
    • Re: C++: PTHREAD_CANCEL_ASYNCHRONOUS and random crash, Dave Butenhof
• Segmentation Fault when I lock a mutex??, Lemko.Corp
  • Re: Segmentation Fault when I lock a mutex??, Paul Pluzhnikov
  • Re: Segmentation Fault when I lock a mutex??, Ian Collins
• Re: vZOOM can handle cross-thread long-term references?, Chris Thomasson
  • Re: vZOOM can handle cross-thread long-term references?, Dmitriy Vyukov
  • <Possible follow-ups>
  • Re: vZOOM can handle cross-thread long-term references?, Chris Thomasson
    • Re: vZOOM can handle cross-thread long-term references?, Chris Thomasson
    • Re: vZOOM can handle cross-thread long-term references?, Dmitriy Vyukov
      • Re: vZOOM can handle cross-thread long-term references?, Dmitriy Vyukov
      • Re: vZOOM can handle cross-thread long-term references?, Dmitriy Vyukov
  • Re: vZOOM can handle cross-thread long-term references?, Chris Thomasson
    • Re: vZOOM can handle cross-thread long-term references?, Dmitriy Vyukov
      • Re: vZOOM can handle cross-thread long-term references?, Chris Thomasson
• Re: A bit more portable DCL (DCI/DCCI) implementation, Dmitriy Vyukov
  • Re: A bit more portable DCL (DCI/DCCI) implementation, Chris Thomasson
  • Re: A bit more portable DCL (DCI/DCCI) implementation, David Schwartz
    • Re: A bit more portable DCL (DCI/DCCI) implementation, Dmitriy Vyukov
      • Re: A bit more portable DCL (DCI/DCCI) implementation, David Schwartz
      • Re: A bit more portable DCL (DCI/DCCI) implementation, Dmitriy Vyukov
      • Re: A bit more portable DCL (DCI/DCCI) implementation, David Schwartz
  • <Possible follow-ups>
  • Re: A bit more portable DCL (DCI/DCCI) implementation, Dmitriy Vyukov
• Re: threaded server using select(), David Schwartz
  • Re: threaded server using select(), Sonny
    • Re: threaded server using select(), David Schwartz
  • <Possible follow-ups>
  • Re: threaded server using select(), Sonny
    • Re: threaded server using select(), David Schwartz

• Security
• UNIX
• Linux
• Coding
• Usenet

• Archive
• About
• Privacy
• Search
• Imprint

newsgroups.derkeiler.com  > Archive  > Comp  > comp.programming.threads  > 2007-08