digitalmars.D.dtl - yamu (yet another mintl update)
- Ben Hinkle (17/17) Sep 02 2004 In anticipation of adding more of Doug Lea's concurrent containers, I've
- antiAlias (26/26) Sep 02 2004 May I comment that I really like what you're doing with this library, Be...
- Sean Kelly (15/19) Sep 03 2004 Is this a direct inclusion of the "concurrent" project? And does this m...
- Ben Hinkle (13/34) Sep 03 2004 the locks stuff is about 1/3 of the concurrent library. The zip file for
- Sean Kelly (6/18) Sep 03 2004 It shouldn't have to. The class is intended to use RAII to avoid the ne...
- Ben Hinkle (6/24) Sep 04 2004 oh ok, now I get it. I was being dense. For some reason I completely ign...
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
Sep 02 2004
"antiAlias" <fu bar.com> 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
Sep 02 2004
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: Sean
Sep 03 2004
In article <chaflk$1tdm$1 digitaldaemon.com>, Sean Kelly says...In article <ch8pl1$12gs$1 digitaldaemon.com>, Ben Hinkle says...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.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 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: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
Sep 03 2004
In article <chb7fe$24sp$1 digitaldaemon.com>, Ben Hinkle says...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. Seanneat 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...
Sep 03 2004
In article <chb9c4$25dv$1 digitaldaemon.com>, Sean Kelly says...In article <chb7fe$24sp$1 digitaldaemon.com>, Ben Hinkle says...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.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.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...
Sep 04 2004