C# threading and synchronizing methods
Taking a look at your Coin class, there are a few things that aren't quite idiomatic C#.
The most obvious thing is that you're using what looks nearly like Java Doc comments. C# uses XML doc comments so this:
/// Constructs a coin.
/// @param aValue the monetary value of the coin
/// @param aName the name of the coin

Should be:
/// &lt;summary&gt;Constructs a Coin.&lt;/summary&gt;
/// &lt;param name=&quot;aValue&quot;&gt;The monetary value of the Coin.&lt;/param&gt;
/// &lt;param name=&quot;aName&quot;&gt;The name of the Coin.&lt;/param&gt;

In C#, we have properties which mean you don't need to write explicit GetXyz and SetXyz. I'm not sure whether you're using an old version of .Net (e.g. using ArrayList) but it's normal to have those as auto-implemented properties like this:
 public double Value { get; }
 public string Name { get; }

If you can't use auto-properties, you'll have to do a bit more typing. I'm going to assume you're stuck on an older .Net and try to avoid newer features.
private readonly double value;
public double Value 
{
    get
    {
        return value;
    }
}

That means you get rid of GetValue and GetName methods. I'd also suggest that you remove the empty constructor to force creation with a value and a name. That only leaves your Equals and GetHashcode implementations.
Let's consider a couple of test cases:
new Coin().Equals(&quot;blah&quot;); // InvalidCastException :(
new Coin().Equals(null); // NullReferenceException :(

Oh dear, we've got a problem here! Let's fix those bugs:
public override bool Equals(Object otherObject)
{
    return Equals(otherObject as Coin);
}

public bool Equals(Coin coin)
{
    if (ReferenceEquals(null, coin))
         return false;

    return coin.Value == this.Value &amp;&amp; coin.Name == this.Name;
}

That's nice and clear and most importantly, is correct! This is a common pattern and you can implement IEquatable at the same time if you want.
I think a coin should have a name in your model so you should validate that in the constructor.
So we're up to here:
/// &lt;summary&gt;
/// A coin with a monetary value.
/// &lt;/summary&gt;
public class Coin : IEquatable&lt;Coin&gt;
{
    private readonly double value;
    
    public double Value
    {
        get
        {
            return value;
        }
    }
    
    private string name;
    
    public string Name 
    {
        get
        {
            return name;
        }
    }

    /// &lt;summary&gt;Constructs a coin.&lt;/summary&gt;
    /// &lt;param name=&quot;value&quot;&gt;The monetary value of the Coin&lt;/param&gt;
    /// &lt;param name=&quot;name&quot;&gt;The name of the Coin&lt;/param&gt;
    public Coin(double value, string name)
    {
        if (name == null)
            throw new ArgumentNullException(&quot;name&quot;);
        this.value = value;
        this.name = name;
    }

    public override bool Equals(Object otherObject)
    {
        return Equals(otherObject as Coin);
    }

    public bool Equals(Coin coin)
    {
        if (ReferenceEquals(null, coin))
            return false;

        return coin.Value == this.Value &amp;&amp; coin.Name == this.Name;
    }
    
    // C# requirement: 
    // since we override Equals, MUST also override GetHashCode ( !! )
    public override int GetHashCode()
    {
        return base.GetHashCode();
    }
    
}

So, only one thing left to talk about: GetHashCode. We must override GetHashCode and implement it correctly. I'll link you to this SO post: https://stackoverflow.com/questions/371328/why-is-it-important-to-override-gethashcode-when-equals-method-is-overridden
Your GetHashCode should look like this:
public override int GetHashCode()
{
    int hash = 13;
    hash = (hash * 7) + Value.GetHashCode();
    hash = (hash * 7) + Name.GetHashCode();
    return hash;
}

Now we've got a class that correctly implements equality.
ETA:
As has been pointed out in the comments, value is a contextual keyword so you may want to think twice before calling a field value. I don't see the problem myself as syntax highlighting in VS, for example, would know it wasn't a keyword. Calling it theValue would be worse for readability in my opinion. If you're on C# 6 or later, you should prefer the auto property so you don't need the field. Either way, if you write this class well at the beginning, the field is an implementation detail and you'll never read this source code again.