This is a much better example. You shouldn't lock this and should lock a
private lock object instead. You shouldn't use volatile since you have more
than one variable that may change at a time. The properties should also lock
the same lock object because you don't want a property to execute in the
You would need to lock as changing the items is not atomic (providing
you want readers to always be in sync i.e. that count and money were
changed at the same time.. but as I said above lock on a private
object don't lock on "this"
Depending on your usage you might also want to consider doing
som
Hi Gregory,
I tried to simplify the class and by doing that, my problem mandates a
simpler solution. Here is a more accurate version of the class:
public sealed class CCTxBatch
{
public CCTxBatch(string strTerminalId)
{
strTerminalId_ = strTerminalId;
}
pu
Yes your code will still work fine. There are however some huge
differences between this code and the original.
1) inlining will not be performed since you have put the lock in (this
will result in a (relatively) significant performance hit compared to
the original)
2) In some cases you will have
Yes, Adam, you are right. The example was derived (simplified) from my real
application. My class has a bunch of integer fields that get incremented
through various methods. I only have "get" properties for them, not because
I wanted them read-only, but because they are changed in bunches.
Anyway,
Well in this exact example, the effect is useless locking. Perhaps you have
a better example?
> -Original Message-
> From: Discussion of advanced .NET topics. [mailto:ADVANCED-
> [EMAIL PROTECTED] On Behalf Of Eddie Lascu
> Sent: Thursday, August 10, 2006 4:25 PM
> To: ADVANCED-DOTNET@DISC
sql 2000 and above you can have indexed views i think, but you have to
create them through t-sql code, not the visual 'view designer'
-Original Message-
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] Behalf Of Aftab A.
Yusufzai Khan
Sent: Thursday, August 10, 2006 5:1
Yes, views can be a performance problem, to do with the table scans, and
indexing (or lack thereof) when i had a huge IN statement querying my view
it caused problems, but on the actual indexed tables, no problem ...
Dean Cleaver <[EMAIL PROTECTED]> wrote: Is that efficient though? I had a
Sorry, the get property should return "strMyField_" and not "strMyFieldId_"
as it does. Just a typo...
-Original Message-
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] Behalf Of Eddie Lascu
Sent: Thursday, August 10, 2006 5:25 PM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.CO
I want to make my class multithread safe. What's the effect of writing
something like this:
public sealed class MyClass
{
public MyClass(string strValue)
{
strMyField_ = strValue;
}
public string MyField
{
get
{
lock(this)
You can also build up a query as a string within your Stored procedure and
then use the EXEC function executing the string .
Phil Sayers <[EMAIL PROTECTED]> wrote: Views are you friend.
create views that each do 4 or 5 joins making sure you SELECT the fields you
need. then use those view
Is that efficient though? I had a similar situation where I had a many
to many relationship between users and programs, so I created a view
that reflected this, and used this view in several other views.
Once the view got to a certain size (the number of rows now exceeds
100,000 easily) all the ot
Views are you friend.
create views that each do 4 or 5 joins making sure you SELECT the fields you
need. then use those views in your main query.
but if you need all the jons, then you may have to resign yourself to "this
is what it takes to get the results as defined by requirements" so you go
Guys,
I'm using SQL Server 2005 and implementing a solution where utilizing the
Xml capabilities will prove quite useful.
However, I have a question that I wanted to see if any of y'all knew or
would know where I might find some help on.
I'm using a PATH mode query (FOR XML PATH syntax) on a qu
Actually from what I have seen the Receive is far more destructive
than the send in most systems (send tends to be very short lived while
receive generally lives alot longer).
As far as whether it makes a copy or not .. it appears to be pinning
the arrays (arraysegments) you hand to it. Here is s
On Thu, 10 Aug 2006 13:03:43 +0100, Ian Griffiths <[EMAIL PROTECTED]>
wrote:
>Doesn't the capture just refer to the WSABUF structures themselves, and
>not the buffers they describe?
That's what I've always assumed, and that's how I've always programmed for
it--the assumption that the buffers need
Doesn't the capture just refer to the WSABUF structures themselves, and
not the buffers they describe?
While it has been about 10 years since I wrote network device drivers
for a living, back then it was very definitely the case that network
cards would work directly with user buffers. (It was tec
Greg, I meant to chime in on this earlier... I'm currently waiting for
further clarification of documentation from Microsoft for WSASend[To]
(which is eventually used by Socket.BeginSend). What I've gotten from
Microsoft so far is that the memory given to WSASend, when asynchronous
(overlapped I/
18 matches
Mail list logo
