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?
I guess so - though I think concurrent is pretty much done except for the 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.