Thread: Semaphores Question

  1. #1
    Registered User ch4's Avatar
    Join Date
    Jan 2007
    Posts
    154

    Semaphores Question

    I have this struct
    Code:
    typedef struct
    {
     int gifts_num;   //Let's say buffer size
     char Gifts[100][128];    //Half function buffer
    
     int elfsOnIt;  //Consumer processes (as mutex)
    
    }bucket;
    My program at first creates many buckets, every bucket has an array of strings(Gifts), a number that shows the quantity of strings (gifts_num) and a variable shows how many child processes working on it.

    The parent process creates all the arrays of all buckets playing the role of producer.(I 've already done this)
    Children processes have to pick one string at a time and place it into a bag.
    In this time i have only Consumers so the problem limited to multiple consumers.

    The problem is that only one process must access the (Gifts) at a time.

    Is it correct to use elfsOnIt as mutex ?
    Is it correct to use gifts_num as buffer size ?
    i think that using only mutex semaphore is enough to do my job. I create 2 plans and i need your suggestions

    Plan A
    P(full)
    P(mutex) //elfsOnIt as mutex
    //Critical Section
    V(mutex)
    V(empty) //gifts_num as empty
    I think that full and empty aren't necessary because i only use Consumers and the problem is limited to that "only one at a time". So i made plan B

    Plan B
    P(mutex) //elfsOnIt as mutex
    //Begin CS
    //bla...bla...bla
    gifts_num--
    //End CS
    V(mutex)
    I think that is better because after picking (or emptying) a string array i don't care about refilling. In simple words, array string is not fully functionable buffer because i only pick, not put things. After picking all stuff from it is useless for me.

    I am pretty sure (so far) that plan B is better for this specific occasion but i 'll wait for your suggestion.

    *Just to mention I use share segments.

  2. #2
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853
    I don't really get plan A to be honest...

    Well, a mutex can be more complicated than increasing decreasing a variable. I believe mutex/semaphors would use pipes or signals to do the job. I also believe you want to do something like:
    Code:
    while (b.elfsOnIt > 0) ;
    b.elfsOnIt++;
    ....
    b.elfsOnIt--;
    Which I don't think is guaranteed to work, because more than one process might execute the while before one executes b.elfsOnIt++. So more than one can pass the "barrier" of while.

    One semaphore is enough since you don't "refill" but it also depends on the implementation.

    Its correct to use gifts_num as the size of the buffer, but not that then it would be better to have
    Code:
    char* Gifts[128];
    and dynamically allocate memory so you don't reserve almost 12Kbytes for every bucket. Which won't be a problem, though, if you don't have a lot of buckets...

    You could of course avoid using gift_num, but I find no reason for doing so...

    EDIT: You also have to take care how to end the child process when you are done

  3. #3
    Registered User ch4's Avatar
    Join Date
    Jan 2007
    Posts
    154
    My problem is to choose the better plan (or create a new one) all the others such as detaching memory/free etc are fine. As far allocation of array that is test don't mind.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Semaphores, need advice on implementation.
    By Swerve in forum C++ Programming
    Replies: 2
    Last Post: 01-13-2009, 01:54 AM
  2. Semaphores Problems
    By mhelal in forum Linux Programming
    Replies: 2
    Last Post: 05-06-2007, 10:36 PM
  3. Debugging question
    By o_0 in forum C Programming
    Replies: 9
    Last Post: 10-10-2004, 05:51 PM
  4. Question...
    By TechWins in forum A Brief History of Cprogramming.com
    Replies: 16
    Last Post: 07-28-2003, 09:47 PM
  5. Question, question!
    By oskilian in forum A Brief History of Cprogramming.com
    Replies: 5
    Last Post: 12-24-2001, 01:47 AM