[lug] Fwd: Simple counter?

[Paul Condon]

On 05/24/2013 11:22 PM, Anthony Foiani wrote:
> Paul Condon<pecondon1 at gmail.com>  writes:
>
>> I take [the existence of lockfile-progs] as proof that the issues
>> involved in a "Simple Counter" have been considered by others before
>> us, and that the full solution will be far from "simple" ;-)
> Aye.
>
>> I suggest a system based on using email and a single mailing list server
>> listening for requests for the 'next' number.
This suggestion is supposed to be a (prototype|test bed), not the final, 
deployed, grand solution.
> Now we're into "mortar as flyswatter" territory.  Possibly "tactical
> nuke as flyswatter".
>
> No doubt that there are situations where this is exactly the correct
> solution.  I can't say that it's the first one that springs to mind,
> though, given the original problem description.
>
>> My belief is, further, that liblockfile is in the public domain and
>> can be ported to any distribution to which it is not already ported,
>> and that this list could be used as a test bed by reserving the
>> subject line "test of simple counter" to identify incoming emails
>> that are intended for the test. Or maybe set up an entirely separate
>> list, but using the existing hardware.
> And now you're so meta that I'm completely lost.  :)
My thought is that, with the suggested test bed, one can emulate the 
behavior of any 'more simple' design and discover whether or not the 
modified design meets the requirements, as augmented by requirements 
discovered by having testers pound away on keyboards of the prototype.
>  From my point of view, it seems clear that there is no one optimal way
> to do it.  The "best way" will depend on the requirements of the given
> use.  Everything from threads within the same process (for which
> atomics is fine, maybe at the cost of a few instructions or a cache
> line invalidation) all the way up to billions of internet hosts (where
> the requirement for unique, sequential numbers is so great that it's
> worth dozens of seconds and millions of cycles and possibly
> non-trivial network bandwidth, let alone connectivity).
>
> And that's ok.  I've had enough issues with projects that are bogged
> down due to "perfect is the enemy of good" impasses.
>
> Happy hacking,
> t.
>
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety