semaphore
parsko
Posts: 501
I got to this part of the manual, and started to get confused.· I feel that I grasp about 75% of the concept.·
Regardless would it be possible·for someone to explain this concept with real life tangible objects, like apples and oranges.· I feel that if I were to read an example of the concept behind these things, I would be much more in the know of how to use them.· Being a mechanical guy, it is easiest for me to concieve a thought with real life objects, not just a register that, for what it is worth, barely exists.
A.K.A.· Why do these exist in the propeller?· Why/how do I use them?
Any thoughts?
-Parsko
PS- PLEASE do not refer me to a wikipedia article.
PPS- I get this warm and fuzzy that someone at Parallax has been waiting for someone like me to ask just such a question, and is REALLY eager to 'splain this to us!·
Regardless would it be possible·for someone to explain this concept with real life tangible objects, like apples and oranges.· I feel that if I were to read an example of the concept behind these things, I would be much more in the know of how to use them.· Being a mechanical guy, it is easiest for me to concieve a thought with real life objects, not just a register that, for what it is worth, barely exists.
A.K.A.· Why do these exist in the propeller?· Why/how do I use them?
Any thoughts?
-Parsko
PS- PLEASE do not refer me to a wikipedia article.
PPS- I get this warm and fuzzy that someone at Parallax has been waiting for someone like me to ask just such a question, and is REALLY eager to 'splain this to us!·
Comments
Say that you have a block of memory(larger than a Long) which contains some sort of record, and one object has as its main task to update this record, and that while it is being updated, other COG/Objects must not read the memory block as it may be inconsistent.
Object_update runs like this:
(Pseudocode)
Loop
If SET_Semaphore
Update_datablock
Release_Semaphore
The other objects must also try to SET_semaphore to see if they can gain access to the resource.
If they get access, they can read it, if not they'll have to try again, until they get access, or go do something else.
What kind of resource that you choose to protect is up to you, though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
They are to avoid 'cross Cog clobbering' when sharing information and related services from the hub. It is like preventing everyone from talking at the same time on a party line.
Am I so old that I am the only one that understands what a party line is? That is when four homes share the same phone number to save money. I suspect it is long gone, like the paper soda straw.
If you really have a need for it, you will understand it. I hope and imagine that it will be part of the tutorial.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
-Parsko
So, any time that you want to stop one COG/Object from changeing a variable while another one uses it, you protect it with a semaphore.
Of course, it's you as a programmer who must decide which resources are to be protected, and that all COG/Objects adhere to it by using Semaphores.
No, there's no 'map' to connect a resource of any kind to a Semaphore.
That is something you will have to do yourself.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Post Edited (Gadgetman) : 5/10/2006 11:45:25 AM GMT
These are need when one Spin Cycle on the HUB isn't enough to complete the task.
But if you think in terms of ARRAYS, then one COG has to do all its reading, writing, or housekeeping before another COG tries to mess with the same ARRAY.
So, the semaphone just keeps the others waiting until the busy COG gets done.
I still do have a clue what kind of task I will be needing them for, but I am sure that will come.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
Imagine there is a restaurant which seats by reservation only. There are X number of tables in the establishment (memory locations). If you have only one maître d' (cog) scheduling reservations for the tables, you dont have any problems, the maître d' has access to the reservation book (index into the memory locations indicating use), and can immediately see if a table is open for the time requested. Now say you have a larger restaurant and need 2 phone lines and 2 maître d' taking reservations, it happens the two phone are located a distance away from each other, but you still only have one reservation book located on a pedestal·between the two phones. Say two calls for·a reservation come in at the same time, and they are trying to reserve a table for the same time, and there is only one table left open for that time. The first maître d' goes over·to the reservation book, sees the opening, and returns to the phone to express that they are in luck, there is one table left open. Meanwhile the other maître d' goes over, also sees their is one table left open (the first hadn't gotten to marking it as reserved yet) and returns to the phone to express that they are in luck, they got the last table availible, and to his suprise when he hangs up the phone and returns to the reservation book,·finds the first maître d' had just marked last table as booked.
This is essentially what can happen when more than one·cog·is trying to access the same data structure when they are both trying to add, or take away from the data structure at the same time (this is called multi-producer, or multi-consumer systems). Using a semaphore is the same as when a maître d' receives a request, he goes over to the reservation book, picks it up and takes it back to the phone where he tells the person on the phone the table is availible and marks it as reserved before returning it to the pedestal. When the second maître d' receives a call for a reservation, he sees the book is being used and says "Can you wait one moment before I can see if the table you requested is availible".
Hope this example helps you to understand where semaphores are useful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1+1=10
Post Edited (Paul Baker) : 5/10/2006 4:01:00 PM GMT
So, the reservation book (semaphore) cannot be changed by anyone other than the maitre dude (hub). BUT, once one is sitting at the table (has control over the variable via one of 8 semaphores), he can order whatever he wants (manipulate the "reserved" variable) all he wants while it is checked out. When the semaphore is checked back in, the variable may exist (be) as a different value.
Is there a reason for only 8 semaphores (is there a reason for more is a better question)? My guess is due to there being 8 bits in a byte and/or 8 cogs/prop.
In theory, if Parallax were to design a new Propeller, could one have more? My guess, yes.
-Parsko
Say the first cog get the pointer to the head of a FIFO, sees its value is 3, writes the data to location 3, increments the pointer to 4, then writes back 4 into the head pointer. This takes a minimum of 3 hub rotations (pointer read, data write, pointer write; properly coded you would actually do pointer read, pointer write, data write: but there is still one hub rotation in there for the pointer update to occur). Now say there is another cog, also trying to add something to the fifo, and it reads the pointer right after the first cog read it, it also sees the value is 3, writes data to location 3, increments the pointer to 4 and writes back 4 to the head pointer. So now after two cogs have accessed the FIFO, the FIFO only shows one data having been added, and the first cog's data has be written over by the second cog.
A semaphore fixes this, by controlling who can access the pointer. If the semaphore is locked, any other cog will see this and know it isn't safe to use yet.
You'll find through experience, that 8 semaphores is more than enough. The reason is that multi-consumer/multi-producer data structures are not that common. Most times you'll have a single producer and a single consumer (such as a FIFO between two cogs to pass data from one to the other). In this case there is no need for semaphores because each cog has its own pointer that only it uses (the producer of data uses the head pointer and the consumer of data uses the tail pointer), so no semaphore is nessesary.
The need of semaphores is actually rare enough, that I requested they provide a dual use in the next generation propeller for conditional execution within assembly programs (like IF_SEM0/IF_NSEM0). In this role they could serve as a general flag (say a half carry, or perhaps a condition settable by another cog whether to execute a portion of code). I do not know whether this will be implemented though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1+1=10
http://forums.parallax.com/showthread.php?p=574710
How do we translate the ma