The signal component allows you to wait for a signal in one thread and trigger the signal in another. A good use case for the signal is for a situation where you need to wait for a control to be created or another control to be destroyed. Without a signal, you can't really wait for both of those events at the same time. You could use the Created/Destroyed events for those controls to trigger the signal (SignalOne method or SignalAll) and call Wait on the Signal component in your automation where you need to detect either of those events.
The lock is somewhat outdated and is mostly replaced by the InteractionFramework. It allows you to "hold" a thread at the lock so only one can go through at a time. Basically, the same as Activities in the Interaction Framework. In the past, you might use it off of a UI event to prevent your automations from launching twice on top of one another.
Is your signal local in Scope? Make sure it is Global or place it in a Global Container. Also, I assume both buttons are on the same windows form. If so, your Click events need to be set to asynchronous or the UI thread will be blocked while those steps are executing. That will prevent you from clicking button 2 until the signal for button 1 has timed out.
What are you trying to use the lock for? It is not commonly used any longer, so I would caution against it unless you have a specific need. It merely holds a thread in-place until the lock has been released. The ReleaseLock must be called on the same thread as RequestLock, or the component will never allow another thread through.