Search code examples
cmultithreadingsocketsposix-select

Use of select or multithread for almost 80 or more clients?


I am working on one project in which i need to read from 80 or more clients and then write their o/p into a file continuously and then read these new data for another task. My question is what should i use select or multithreading?

Also I tried to use multi threading using read/fgets and write/fputs call but as they are blocking calls and one operation can be performed at one time so it is not feasible. Any idea is much appreciated.

update 1: I have tried to implement the same using condition variable. I able to achieve this but it is writing and reading one at a time.When another client tried to write then it cannot able to write unless i quit from the 1st thread. I do not understand this. This should work now. What mistake i am doing?

Update 2: Thanks all .. I am able to succeeded to get this model implemented using mutex condition variable.

updated Code is as below:

        **header file*******
         char    *mailbox ;
    pthread_mutex_t  lock  = PTHREAD_MUTEX_INITIALIZER ;
    pthread_cond_t   writer = PTHREAD_COND_INITIALIZER;

    int main(int argc,char *argv[])
    {
      pthread_t          t1 , t2;
      pthread_attr_t     attr;
      int            fd, sock , *newfd;
      struct sockaddr_in cliaddr;
      socklen_t      clilen;
      void          *read_file();
      void          *update_file();

      //making a server socket
      if((fd=make_server(atoi(argv[1])))==-1)
        oops("Unable to make server",1)


      //detaching threads
      pthread_attr_init(&attr);
      pthread_attr_setdetachstate(&attr,PTHREAD_CREATE_DETACHED);

      ///opening thread for reading
      pthread_create(&t2,&attr,read_file,NULL);

      while(1)
      {
        clilen = sizeof(cliaddr);
        //accepting request
        sock=accept(fd,(struct sockaddr *)&cliaddr,&clilen);

        //error comparison against failire of request and INT
        if(sock==-1 && errno != EINTR)
                oops("accept",2)
        else if ( sock ==-1 && errno == EINTR)
            oops("Pressed INT",3)

        newfd = (int *)malloc(sizeof(int));
        *newfd = sock;
        //creating thread per request
        pthread_create(&t1,&attr,update_file,(void *)newfd);
      } 
     free(newfd);
     return 0;
    }

    void *read_file(void *m)
    {
        pthread_mutex_lock(&lock);
        while(1)
        {
            printf("Waiting for lock.\n");
        pthread_cond_wait(&writer,&lock);
            printf("I am reading here.\n");
            printf("%s",mailbox);
            mailbox = NULL ;
        pthread_cond_signal(&writer);
        }
    }


    void *update_file(int *m)
    {
       int  sock = *m;
       int  fs ; 
       int  nread;
       char buffer[BUFSIZ] ;

       if((fs=open("database.txt",O_RDWR))==-1)
          oops("Unable to open file",4)

       while(1)
       {
        pthread_mutex_lock(&lock);
        write(1,"Waiting to get writer lock.\n",29);

        if(mailbox != NULL)
           pthread_cond_wait(&writer,&lock);

            lseek(fs,0,SEEK_END);
            printf("Reading from socket.\n");
            nread=read(sock,buffer,BUFSIZ);
            printf("Writing in file.\n");
            write(fs,buffer,nread);
            mailbox = buffer ;
          pthread_cond_signal(&writer);
          pthread_mutex_unlock(&lock);
       }
        close(fs);
    }

Solution

  • I think for the the networking portion of things, either thread-per-client or multiplexed single-threaded would work fine.

    As for the disk I/O, you are right that disk I/O operations are blocking operations, and if your data throughput is high enough (and/or your hard drive is slow enough), they can slow down your network operations if the disk I/O is done synchronously.

    If that is an actual problem for you (and you should measure first to verify that it really is a problem; no point complicating things if you don't need to), the first thing I would try to ameliorate the problem would be to make your file's output-buffer larger by calling setbuffer. With a large enough buffer, it may be possible for the C runtime library to hide any latency caused by disk access.

    If larger buffers aren't sufficient, the next thing I'd try is creating one or more threads dedicated to reading and/or writing data. That is, when your network thread wants to save data to disk, rather than calling fputs()/write() directly, it allocates a buffer containing the data it wants written, and passes that buffer to the IO-write thread via a (mutex-protected or lockless) FIFO queue. The I/O thread then pops that buffer out of the queue, writes the data to the disk, and frees the buffer. The I/O thread can afford to be occasionally slow in writing because no other threads are blocked waiting for the writes to complete. Threaded reading from disk is a little more complex, but basically the IO-read thread would fill up one or more buffers of in-memory data for the network thread to drain; and whenever the network thread drained some of the data out of the buffer, it would signal the IO-read thread to refill the buffer up to the top again. That way (ideally) there is always plenty of input-data already present in RAM whenever the network thread needs to send some to a client.

    Note that the multithreaded method above is a bit tricky to get right, since it involves inter-thread synchronization and communication; so don't do it unless there isn't any simpler alternative that will suffice.