• Ben Hinkle <bhinkle4 juno.com> Sep 02 2004
• "antiAlias" <fu bar.com> Sep 02 2004
• Sean Kelly <sean f4.ca> Sep 03 2004
• Ben Hinkle <Ben_member pathlink.com> Sep 03 2004
• Sean Kelly <sean f4.ca> Sep 03 2004
• Ben Hinkle <Ben_member pathlink.com> Sep 04 2004

In anticipation of adding more of Doug Lea's concurrent containers, I've
added a companion library to mintl to the mintl.zip file. The companion
library is a set of locks and synchronization constructs (also from Doug
Lea, hmmmm...). It basically just has locks, condition variables and a few
nifty helpers like a count-down latch, a semaphore, a cyclic barrier and a
read-write lock. Besides that I added a heap to mintl proper (a heap is an
array where x[n] is greater than x[2*n+1] and x[2*n+2]). Heaps are
typically used to implement priority queues.

usual site
 http://home.comcast.net/~benhinkle/mintl/
The locks library documentations is at
 http://home.comcast.net/~benhinkle/mintl/locks.html
but you can also get to that page from the main mintl page so don't worry if
you lose that.

I'll get back to this after the long weekend so expect more late next week
or even the week after that.

-Ben

May I comment that I really like what you're doing with this library, Ben?
It's simple, familiar, and straightforward. A minor quibble would be the
lack of examples for complete newbies.

I wonder if someone else would be willing to take on documentation tasks
like that? Surely there are some capable writers amongst the NG
participants, who'd like to contribute also ... ?

- Kris



"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:ch8pl1$12gs$1 digitaldaemon.com...
In anticipation of adding more of Doug Lea's concurrent containers, I've
added a companion library to mintl to the mintl.zip file. The companion
library is a set of locks and synchronization constructs (also from Doug
Lea, hmmmm...). It basically just has locks, condition variables and a few
nifty helpers like a count-down latch, a semaphore, a cyclic barrier and a
read-write lock. Besides that I added a heap to mintl proper (a heap is an
array where x[n] is greater than x[2*n+1] and x[2*n+2]). Heaps are
typically used to implement priority queues.

usual site
 http://home.comcast.net/~benhinkle/mintl/
The locks library documentations is at
 http://home.comcast.net/~benhinkle/mintl/locks.html
but you can also get to that page from the main mintl page so don't worry if
you lose that.

I'll get back to this after the long weekend so expect more late next week
or even the week after that.

-Ben

In article <ch8pl1$12gs$1 digitaldaemon.com>, Ben Hinkle says...
In anticipation of adding more of Doug Lea's concurrent containers, I've
added a companion library to mintl to the mintl.zip file. The companion
library is a set of locks and synchronization constructs (also from Doug
Lea, hmmmm...).


Is this a direct inclusion of the "concurrent" project?  And does this mean that
project is still on track?  I saw the that there hadn't been any updates in the
past few months and wondered...  Assuming it is, that's fantastic.  The stuff
that's there should be more than enough to get started, though it would be nice
to have a scoped lock wrapper:

# auto class ScopedLock
# { 
# public:
#     this( Lock l ) { lock = l; lock.lock(); }
#     ~this() { lock.unlock(); }
# private:
#     Lock lock;
# }


Sean

In article <chaflk$1tdm$1 digitaldaemon.com>, Sean Kelly says...
In article <ch8pl1$12gs$1 digitaldaemon.com>, Ben Hinkle says...
In anticipation of adding more of Doug Lea's concurrent containers, I've
added a companion library to mintl to the mintl.zip file. The companion
library is a set of locks and synchronization constructs (also from Doug
Lea, hmmmm...).


Is this a direct inclusion of the "concurrent" project?  


the locks stuff is about 1/3 of the concurrent library. The zip file for
concurrent hasn't been updated in a while but the repository has pretty much
what I put into mintl.zip. The differences are in module names, help formatting
and the different compare-and-set functions.

And does this mean that project is still on track?  


containers part and that was partly why I started up on mintl. Mike had been
working on the lightweight fork/join threading classes but when Doug recommended
we go to the JSR166 codebase I don't know if Mike lost steam. That was probably
my fault for wasting time with Dougs original code.

I saw the that there hadn't been any updates in the
past few months and wondered...  Assuming it is, that's fantastic.  The stuff
that's there should be more than enough to get started, though it would be nice
to have a scoped lock wrapper:

# auto class ScopedLock
# { 
# public:
#     this( Lock l ) { lock = l; lock.lock(); }
#     ~this() { lock.unlock(); }
# private:
#     Lock lock;
# }


neat idea - I will think about that. I wonder, though, about auto with locks
since auto variables live on one stack and threads live across stacks - so how
would one thread know about another thread's auto lock? will ponder that one...

Sean

In article <chb7fe$24sp$1 digitaldaemon.com>, Ben Hinkle says...
# auto class ScopedLock
# { 
# public:
#     this( Lock l ) { lock = l; lock.lock(); }
#     ~this() { lock.unlock(); }
# private:
#     Lock lock;
# }


neat idea - I will think about that. I wonder, though, about auto with locks
since auto variables live on one stack and threads live across stacks - so how
would one thread know about another thread's auto lock? will ponder that one...


It shouldn't have to.  The class is intended to use RAII to avoid the need for
explicit calls to unlock in "finally" or "catch" blocks.  Entering threads would
wait on the lock just as if the auto class weren't there, since the auto class
just forwards all the work to the underlying lock anyway.

Sean

In article <chb9c4$25dv$1 digitaldaemon.com>, Sean Kelly says...
In article <chb7fe$24sp$1 digitaldaemon.com>, Ben Hinkle says...
# auto class ScopedLock
# { 
# public:
#     this( Lock l ) { lock = l; lock.lock(); }
#     ~this() { lock.unlock(); }
# private:
#     Lock lock;
# }


neat idea - I will think about that. I wonder, though, about auto with locks
since auto variables live on one stack and threads live across stacks - so how
would one thread know about another thread's auto lock? will ponder that one...


It shouldn't have to.  The class is intended to use RAII to avoid the need for
explicit calls to unlock in "finally" or "catch" blocks.  Entering threads would
wait on the lock just as if the auto class weren't there, since the auto class
just forwards all the work to the underlying lock anyway.


oh ok, now I get it. I was being dense. For some reason I completely ignored the
lock being passed into the ScopedLock constructor :P
So it is just like the synchronized statement except for Locks instead of object
monitors. I like that. I will definitely add it - maybe right in the lock.d
module after the interface for Lock.