Can i change value of a named semaphore?

I was hoping to change the value of a named semaphore in one instruction, like the inverse of sem_getvalue.

I have tried this and it worked:

Code:

---

(*Sem).__align=x;

---

(tough i have to do one sem_post() after that instruction so that the processes waiting on the semaphore realize it has been changed)
my question is: is this safe? Does that __align field has the same name in other systems?

the alternative is to do multiple sem_post(), but i want to avoid that...

Thank You

What are you ACTUALLY trying to achieve. Modifying the internals of a semaphore outside of the functions exported for that purpose will be completely undefined. In most systems, modifying a semaphore is a set of several operations to ensure that one, and only one, thread/process can perform the change at any given time, to avoid nasty effects (race-conditons - and the whole point of semaphores over regular variables is that they can be relied upon as inter-process communication mechanisms. If you start modifying the semaphore outside of those constraints, you are "breaking the rules".

Edit: To put it another way: You are using matches to try to see if the petrol tank is empty - bad idea.

--
Mats

and is there any safe way to do this?
have a semaphore at 0 and then change it to n, so that n child processes can start going again after been frozen by sem_wait().?

semctl() or semop() perhaps?

There are 2 semaphore API's:
SYSV: semctl, semget, and semop.
POSIX: sem_close, sem_destroy, sem_getvalue, sem_init, sem_open, sem_post, sem_timedwait, sem_trywait, sem_unlink, and sem_wait.

There is no "setvalue(n)" in the Posix API, but it's not too difficult to create your own...

Code:

---

for (i = 0; i < n; ++i)
    sem_post(sem);

---

gg

Quote:

---

Originally Posted by Ironic

and is there any safe way to do this?
have a semaphore at 0 and then change it to n, so that n child processes can start going again after been frozen by sem_wait().?

---

Perhaps figuring out why they freeze is a better solution? Seriously, if you think that resetting the semaphore is a good idea, you probably aren't using semaphores correctly, as the reason you SHOULD be using semaphores is to signal information/state between threads/processes. If that signalling is broken, and you "fix it" by resetting the semaphore, I think you will find that something else is going to go wrong, and you will end up with something else going wrong soon after.

And of course, if that is what you want to achieve, just setting the internal counter in the semaphore will not do what you want, because the OS internal functions that handle the case of "thread/process X is now runnable" - there's no special magic about the location the semaphore lives at, so the logic of enabling the scheduler is handled by the semaphore code itself, inside the kernel.

--
Mats

my idea is to send a message from a father to n child processes.

i am planning to use shared memory to do this.

This is going to be evaluated, so i want to make it efficient, like if i had large numbers of child processes.

My idea is to put all the child's to sleep via a semaphore, so that they don't take up any resources when they are waiting for the message. Then in the father, i put the message in the shared memory and unlock the semaphore. The problem is that when the sem_wait in the child returns, it locks the semaphore again. i could do a sem_post right after, but that would mean that the child's would read the memory one at a time.
Since the children will only read, and not write to that memory segment, there would not be any problem to allow them all to read it at once, what would make the program faster...

Huh?

So, you are writing something to shared memory that needs to be processed by N processes, and all N processes are waiting for ONE semaphore. Then when each of the N processes are finished, they do sem_wait, which blocks the process again.

I personally would have one (or even two) semaphore(s) per process myself, and signal each process in turn - it won't take that long (unless the child processes have a higher priority than the main process - which would be bad) to signal a number of semaphores. The second semaphore would indicate when each of the children have finished.

--
Mats

http://en.wikipedia.org/wiki/Semaphore_(programming)
http://www.tin.org/bin/man.cgi?section=3&topic=sem_init
You initialise the semaphore to some N
You're allowed to call sem_wait() N times in succession before blocking.
At some point, there will be N sem_post() calls to return the semaphore to it's initial state.

Are you saying you want to change N after you've created it?

yes, what i want is to have the semaphore locked, and then change the value to N, being N the number of children, so that all of them start accessing the memory.

Seems i will have to use N sem_post. not in one instruction how i hoped, but it works

Thank You all