Bug 20585

Summary: Problems with threading and device access
Product: [Retired] Red Hat Linux Reporter: tjfalcone <afalcone>
Component: kernelAssignee: Michael K. Johnson <johnsonm>
Status: CLOSED NOTABUG QA Contact: Brock Organ <borgan>
Severity: high Docs Contact:
Priority: high    
Version: 7.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-12-15 03:28:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description tjfalcone 2000-11-09 15:17:46 UTC
I am having problems with g++ and pthreads, which is affecting the way the
artsd sound
daemon (in KDE 2.0) accesses the sound device.

My understanding of the way the daemon works is this: when a user starts a
session (e.g., by
placing "startkde" in her .xinitrc), the sound daemon artsd is started.  It
is responsible for 
multiplexing sound events.  It accomplishes this, in part, by spawning
threads which listen to
various "sound-requiring" programs, like KDE's "kaiman."

The problem is that the kernel doesn't seem to like it when different
threads access the same
device, even if they are all associated to the same process.  For example,
I have run the
following test code:

#include <pthread.h>
#include <iostream.h>
#include <stdio.h>
#include <unistd.h>


static void *playerThread(void *arg)
{
  cout << "In playerThread now." << endl;
  while(1) {
    cout << "Here is thread A" << endl;
    sleep(5);
  }
  return NULL;
}
 
int main(int argc, char** argv)
{
  pthread_t tr;
 
  sleep(10);
  if (pthread_create(&tr,NULL,playerThread,NULL) != 0) {
    perror("Error in thread.");
  }
  sleep(2);  //  critical delay time!!
  while(1) {
    cout << "Thread main - sleeping for ten seconds." << endl;
    sleep(10);
  }
}                                                                               

By adjusting the "critical delay time," I can make either the main thread
or the spawned 
thread print to cout, and, rarely, get both to print, though only
intermittently.  If I change the
code so that the thread prints to cerr, then the code does just what it is
supposed to.

I am assuming that this is a bug in 7.0, since the same code in RH 6.1
works exactly the
way it is supposed to, and esd (the Enlightenment sound daemon) appears to
multiplex sound
events properly on this system.  (I am running Gnome on the RH 6.1 system
and KDE 2.0 on the RH 7.0 system, just for kicks.)

Please let me know what can be done to correct this problem, as I am sure
that I am not the
only person experiencing it.

Thanks in advance.

Comment 1 Arjan van de Ven 2001-01-16 09:33:39 UTC
Your test-program seems to have nothing to do with the sounddaemon problem. Your
program
suffers from some issue in stdout buffering that may or may not be  bug in
glibc, I bet once you
add a \n to the textstrings the issue is gone.