Semaphore Lock for Dummies

Yes. I'm sorry. I originally thought you meant two different copies of the same macro. It seems you mean two different macros. Your last post is the correct solution. Use the same semaphore name in each Macro that you want to protect them both from simultaneously running.

I presume we're all on the same page now, - no more ifs, ands or butts.

1 Like

Yep.

That's exactly what I said above:

1 Like

Except my typing butt, of course. Thanks all for the help. This has really upped my output at work. How do people survive without this application?

1 Like

I had the same confusion, and had been avoiding using semaphores because I could not figure out how -- thank you for (re)phrasing this so clearly!

Can the wiki be updated to reflect this clarification?

1 Like

Yes, now that KM9 has been released and the Wiki is now editable again.
It may take a few days, but I'll try to get to it soon.

Just so I know which language you found more useful, which post or posts did you find most helpful in clarifying use of semaphores?

Thanks! I was replying to CJK's post #6 here, but given the chance I'll edit their text a bit more, and suggest

"If you want to prevent certain macros from executing simultaneously, place a Semaphore Lock Action as the first action in each one, and assign them all the same Semaphore Name. While a macro that begins with a Semaphore Lock Action is executing, no other macro that begins with a Semaphore Lock Action that has the same Semaphore Name will execute. If such a macro (or another instance of the first macro) is triggered, it will wait to execute until after the first macro ends, which automatically unlocks that semaphore."

This may be rather painstakingly detailed, and I'm sure it could be improved further, but I hope it's clearer to users like CJK and me?

5 Likes

@Shoshanna, many thanks for providing an excellent draft for the wiki.

Well that part's not always true. A semaphore can have a timeout and a flag that determines what happens when it times out. That statement is only true for the default configuration of a semaphore. I use timeouts on semaphores almost all the time, so that statement is almost never true for me.

Good catch, thanks! @JMichaelTX, let's make that line "it will wait to execute until the semaphore is unlocked" (unless that too has a problem I'm not seeing).

I'm glad you weren't angry at me. Sometimes people take my comments as argumentative.

1 Like

Heh, well, I'm actually a professional editor, so it would be awfully hypocritical of me to get bent out of shape when someone catches a problem in my writing! And certainly I want the wiki to be the best it can be :sweat_smile:

1 Like

I did wonder about the precision-wording of your blurb. It's well-explained, and grammatically sound, which struck me almost immediately.

1 Like

Hey guys, thanks for your feedback.
I've revised the KM Wiki article Semaphore Actions as follows:

The primary purpose of using a Semaphore Lock is to prevent simultaneous macro executions of the same, or related, macros.
In order to achieve this:

  • Place a Semaphore Lock Action (using the same Semaphore Name) as the first action of each Macro that you wish to prevent executing simultaneously.

  • The lock will remain in place preventing any other macros that try to execute until the first macro completes, or until you execute a Semaphore Unlock action.

  • You can also cause all additional macro instances to be immediately cancelled by setting a very short timeout (1 hundredth of a second) for the Semaphore Action.

Please let us know if this clears things up, or if you have further suggestions.

Some of that wording is confusing to me, I'm afraid!

In the title: saying this is the primary purpose connotes that there is at least one other (secondary) purpose; what is it? I'm left wondering. Also, the line should be "simultaneous executions of the same, or related, macros"; delete the redundant word "macro" after "simultaneous."

I think the first sentence (first bullet point) would be clearer if you moved the parenthetical: "Place a Semaphore Lock Action as the first action of each Macro that you wish to prevent executing simultaneously, using the same Semaphore Name in each."

The second sentence (second bullet point) isn't grammatical, I'm afraid. Also, the semaphore lock doesn't prevent any other macros from editing, only the other macros with a semaphore with the same name. The sentence could be corrected as "The lock will remain in place, preventing the other macros from executing, until the first macro completes or until the semaphore is unlocked with a Semaphore Unlock action." I revised the last few words because the user doesn't have to execute the unlock action themselves, right?

But this doesn't make clear whether those other macros, which were triggered while the semaphore was locked, will just never execute, or will execute once the semaphore is unlocked. I believe the latter is correct? I wouldn't use a semaphore without being sure of this point; I think it needs to be clear. But then there's the third sentence...

I don't understand the third sentence at all, I'm afraid. What "Semaphore Action" is meant here; the Semaphore Lock Action? How does having the semaphore be locked for only a fraction of a second cancel anything? The phrase "be immediately cancelled" suggests that other macros with the same semaphore are already executing, but that's impossible, right? Once one of these macros begins executing no other one of them can start, because the semaphore is locked, so I don't know what you mean here. Also, does "macro instances" here mean all the macros with the same Semaphore Name? I tend to think of "instances" as meaning "instantiations of the same thing," so you might speak of several instances of the same macro, but not of "macro instances" as meaning several different macros. Basically, this sentence leaves me quite confused.

Lastly, I'd advise making the sentence " The Semaphore actions take a name, and different names can be used for different (independent) locks" the first sentence of the first bullet point, which is where the naive reader learns about naming semaphore locks.

Sorry to be troublesome, and thank you for your work!

2 Likes

No problem! I really appreciate your constructive and detailed feedback.

Agreed. Rewritten removing "primary purpose".

Well, this is a complex sentence, and another user remarked about confusion of the name. To me, having the "(using the same Semaphore Name)" immediately following " Place a Semaphore Lock Action" removes all ambiguity.
So, I'll have to disagree on this one, and keep it as is.

Agreed. Change to use your text.

Seems like this is made clear by:

The lock will remain in place, preventing the other macros from executing, ==until the first macro completes== or until the semaphore is unlocked with a Semaphore Unlock action.

So I don't see the need for any change there.

OK, is this clearer?

You can also cause all additional macro instances to be immediately cancelled by setting a very short timeout (1 hundredth of a second) for the ==Semaphore Lock Action==. ==When the Semaphore Local Action times out, it cancels the pending execution of that macro instance.==

"Macro instances" can be confusing. Basically, every time a Macro executes, it is an "instance".
So in this context, "macro instances" refers to both additional instances of the same macro and instances of other macros that use the same named Semaphore Lock Action.

I will add a footnote defining "macro instance"

Actually that statement needs to be above the bullet list, which is where I have put it.

Thanks again for your helpful feedback.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To All:

Based on and inspired by the feedback from @Shoshanna, I have made another major revision.
Rather than posting a quote of it here, please read the entire article so that this section is understood in context.

All constructive comments welcome!

Semaphore Actions -- KM Wiki

Maybe I ate some paint off the wall in the 70s ( "Lead paint" Get it? :sweat_smile:) but I still don't understand "You can also cause all additional macro instances to be immediately cancelled by setting a very short timeout (1 hundredth of a second) for the Semaphore Lock Action. When the Semaphore Local Action times out, it cancels the pending execution of that macro instance."

Can you perhaps give an example of why would it be desired to cancel all additional instances? Sorry but I've read it about five times and still don't get why would this be necessary/desired.

IME, this has most often occurred when a Macro is triggered automatically by something other than a direct user trigger, like a hot key.

For example, I have a Macro that moves the mouse to the current window whenever a new window is activated, OR the current window is moved. So, if I am dragging a window from one screen to another, I don't want the Macro to actually execute with every minute movement of the window. So I have a Semaphore that cancels new instances. I don't want to process any new instances until the current one is completed, AND I don't want to queue up instances.

I hope that makes sense.

I think I understand now but I'll fully understand it once I actually make use of this technique. By the way, interesting macro about moving the pointer to a newly activated window. What's the benefit of this if I may ask? Is it to save some wrist by having to move the mouse less (which over time I can see that making a significant difference).

I have two large 27-monitors, and I can easily switch to another app in the other screen, and having the mouse automatically follow this is very, very useful and efficient. Not only does this macro move the mouse to the new active window, but it moves it to a preset, relative position for that specific app and window.

1 Like