headers
Daryle Walker | 1 Sep 2000 01:04
Picon

Re: Threads: Atomic Counter

on 8/30/00 10:05 PM, William Kempf at sirwillard <at> my-deja.com wrote:

> Atomic counters are integral types that can be manipulated through
> atomic functions, functions gauranteed to execute from start to end
> with out fear of pre-emption causing corruption.  Many platforms have
> native operations that allow atomic operations on native integral
> types, but we can't rely on this being the case.  So, we need a type
> other than the built in integral types that we can build the
> necessary synchronization into for platforms with out such atomic
> operations.

Doesn't C ,and therefore C++, have a "sig_atomic_t" type that works like
this?  (I mentioned this type during the thread discussions.)  Could we use
it somehow, without (always) resorting to platform-specific extensions?

--

--
Permalink | Reply | 8 comments |
headers
jsiek | 1 Sep 2000 02:19
Picon

Re: [Review] Boost Graphs Library (GGCL)

Jens Maurer writes:
 > template<class T>
 > struct my_set_adaptation : std::set<T, jens::less<T> >
 > {
 >   /* add constructors here */
 > };
 > 
 > The disadvantage is that you have to write forwarding functions for
 > the required constructors.  (This particular example doesn't make
 > much sense, because the actual type for T is hidden, so I have a
 > hard time writing a sensible jens::less<T>.)

This deserves some more thought, because I think it is important to be
able to specify your own ordering via jens::less<T>.  For example,
Beman mentioned out-edge ordering as one of the important things for
planar graphs. I think I'll need to create an interface for being able
to somehow extract the target vertex from objects of type T.

Cheers,

Jeremy
Permalink | Reply | 0 comments |
headers
jsiek | 1 Sep 2000 02:21
Picon

RE: [Review] Boost Graphs Library (GGCL)

Gary Powell writes:
 > The other disadvantage is that maybe some compiler which ggcl currently
 > supports doesn't support template template's. This of course is a tough
 > choice, make a bad design decision now because of lack of support and years
 > later we'll still be stuck with it.

I know of only one compiler (g++) that supports template templates.
Are there any others?

Cheers,

Jeremy
Permalink | Reply | 4 comments |
headers
jsiek | 1 Sep 2000 02:38
Picon

Re: [Review] Boost Graphs Library (GGCL)

Jens Maurer writes:
 >  - A single size_type as shown in adjacency_list (doc 8.1.5) for both
 > edge and vertex numbers is not enough when edge and vertex containers
 > differ in their size_type.

So there are several functions that are affected by this issue:

num_vertices(g)
num_edges(g)
degree(v, g), out_degree(v, g), in_degree(v, g)

So we'd really need three different size types:
  vertices_size_type
  edges_size_type
  degree_size_type

I hesitated from doing this before because of the added complexity/
confusion of the interface. However, it is the "right" thing to do.

Ciao,

Jeremy
Permalink | Reply | 0 comments |
headers
Gary Powell | 1 Sep 2000 02:40

RE: [Review] Boost Graphs Library (GGCL)

Comeau 4.2.44 claims it has this feature on their web page, I don't have a
copy so I can't verify it.  http://www.comeaucomputing.com

Since you have KAI, I assume that's not currently a supported compiler? (I
can't tell from the PR junk on the web page.)

  -gary-


> -----Original Message-----
> From:	jsiek <at> lsc.nd.edu [SMTP:jsiek <at> lsc.nd.edu]
> Sent:	Thursday, August 31, 2000 5:22 PM
> To:	boost <at> egroups.com
> Subject:	RE: [boost] [Review] Boost Graphs Library (GGCL)
> 
> Gary Powell writes:
>  > The other disadvantage is that maybe some compiler which ggcl currently
>  > supports doesn't support template template's. This of course is a tough
>  > choice, make a bad design decision now because of lack of support and
> years
>  > later we'll still be stuck with it.
> 
> I know of only one compiler (g++) that supports template templates.
> Are there any others?
> 
> Cheers,
> 
> Jeremy
> 
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Greg Colvin | 1 Sep 2000 02:32
Picon

Re: Re: Threads: Atomic Counter

From: Daryle Walker <darylew <at> mac.com>
> 
> Doesn't C ,and therefore C++, have a "sig_atomic_t" type that works like
> this?  (I mentioned this type during the thread discussions.)  Could we use
> it somehow, without (always) resorting to platform-specific extensions?

In a word, no.  The C and C++ standards promise very little
(some would argue nothing) of any real use about sig_atomic_t.
Permalink | Reply | 7 comments |
headers
jsiek | 1 Sep 2000 03:01
Picon

RE: [Review] Boost Graphs Library (GGCL)

Gary Powell writes:
 > Comeau 4.2.44 claims it has this feature on their web page, I don't have a
 > copy so I can't verify it.  http://www.comeaucomputing.com
 > 
 > Since you have KAI, I assume that's not currently a supported compiler? (I
 > can't tell from the PR junk on the web page.)

Right, KAI doesn't support template templates. (at least the version
I have, with EDG front end version 2.41.2 doesn't)

Cheers,

Jeremy
Permalink | Reply | 0 comments |
headers
Valentin Bonnard | 1 Sep 2000 05:15
Picon

Re: Re: Threads: Atomic Counter

On Thu, Aug 31, 2000 at 12:30:22PM -0400, David Abrahams wrote:
> 
> ----- Original Message -----
> From: "William Kempf" <sirwillard <at> my-deja.com>
> > > The following Win32 functions don't work right on Win95:
> > >
> > > InterlockedCompareExchange
> > > InterlockedCompareExchangePointer
> > > InterlockedExchangeAdd
> >
> > But they do on Win98.  Tricky issue here.  I included the
> > compare_exchange() only to bring up debate about its usefulness.
> > I've never found a need for them, but didn't want to eliminate them
> > just because I've never needed them, nor because Win95 didn't support
> > them.  Obviously they can be added to Win95 in the form of some
> > assembler instructions.
> 
> Just an additional data point: if I remember correctly, the Motorola 680x0,
> where x > 2, includes atomic instructions for linking list elements in/out
> of singly- and doubly-linked lists! These are called something like
> "Atomic-compare-and-exchange" IIRC.

Insert in singly linked list:

inserted->next = pos->next;
pos->next = inserted;

This can't be done atomically, even which get_and_set (but each assignment 
can be done atomically)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Greg Colvin | 1 Sep 2000 06:20
Picon

Re: Re: Threads: Atomic Counter

From: Valentin Bonnard <Bonnard.V <at> wanadoo.fr>
> On Thu, Aug 31, 2000 at 12:30:22PM -0400, David Abrahams wrote:
> > 
> > From: "William Kempf" <sirwillard <at> my-deja.com>
> > > > The following Win32 functions don't work right on Win95:
> > > >
> > > > InterlockedCompareExchange
> > > > InterlockedCompareExchangePointer
> > > > InterlockedExchangeAdd
> > >
> > > But they do on Win98.  Tricky issue here.  I included the
> > > compare_exchange() only to bring up debate about its usefulness.
> > > I've never found a need for them, but didn't want to eliminate them
> > > just because I've never needed them, nor because Win95 didn't support
> > > them.  Obviously they can be added to Win95 in the form of some
> > > assembler instructions.
> > 
> > Just an additional data point: if I remember correctly, the Motorola 680x0,
> > where x > 2, includes atomic instructions for linking list elements in/out
> > of singly- and doubly-linked lists! These are called something like
> > "Atomic-compare-and-exchange" IIRC.
> 
> Insert in singly linked list:
> 
> inserted->next = pos->next;
> pos->next = inserted;
> 
> This can't be done atomically, even which get_and_set (but each assignment 
> can be done atomically)
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Abrahams | 1 Sep 2000 06:47
Picon

Re: Re: Threads: Atomic Counter


----- Original Message -----
From: "Valentin Bonnard" <Bonnard.V <at> wanadoo.fr>

> Insert in singly linked list:
>
> inserted->next = pos->next;
> pos->next = inserted;
>
> This can't be done atomically, even which get_and_set (but each assignment
> can be done atomically)
>
>
> Remove from singly linked list:
>
> // at this point removed_prev.next == removed
> removed_prev->next = removed->next;
>
> MOVE (next,removed), (next,removed_prev)
>
> (Atomic on every 68k)
>
>
> Remove from doubly linked list:
>
> removed->prev->next = removed->next;
> removed->next->prev = removed->prev;
>
> IMO this can't be done atomically (but each assignment can be done
> atomically).
(Continue reading)

Permalink | Reply | 0 comments |

Gmane