Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
the google bard and a mutual exclusion lock...
58 views
Skip to first unread message
Chris M. Thomasson
Apr 18, 2023, 10:06:17 PM4/18/23
to
Well, it gave me code filled with bugs when I asked it to show me where
to place the memory barriers in a mutual exclusion lock:
https://i.ibb.co/fYDRNsw/image.png
___________________________
// A mutual exclusion lock.
class Mutex
{
private:
// The lock variable.
volatile bool lock;
public:
// Acquires the lock.
void Acquire()
{
// Ensure that the following operations are performed in the
correct order.
__asm__ volatile("mfence");
lock = true;
}
// Releases the lock.
void Release()
{
// Ensure that the following operations are performed in the
correct order.
lock = false;
__asm__ volatile("mfence");
}
};
___________________________
It put the membars in the wrong places and did not even think about
atomically acquire and releasing the mutex. I feel like correcting it,
but why would I do that? Yikes! What a nightmare!
to place the memory barriers in a mutual exclusion lock:
https://i.ibb.co/fYDRNsw/image.png
___________________________
// A mutual exclusion lock.
class Mutex
{
private:
// The lock variable.
volatile bool lock;
public:
// Acquires the lock.
void Acquire()
{
// Ensure that the following operations are performed in the
correct order.
__asm__ volatile("mfence");
lock = true;
}
// Releases the lock.
void Release()
{
// Ensure that the following operations are performed in the
correct order.
lock = false;
__asm__ volatile("mfence");
}
};
___________________________
It put the membars in the wrong places and did not even think about
atomically acquire and releasing the mutex. I feel like correcting it,
but why would I do that? Yikes! What a nightmare!
Chris M. Thomasson
Apr 18, 2023, 11:18:29 PM4/18/23
to
On 4/18/2023 7:05 PM, Chris M. Thomasson wrote:
> Well, it gave me code filled with bugs when I asked it to show me where
> to place the memory barriers in a mutual exclusion lock:
>
> https://i.ibb.co/fYDRNsw/image.png
>
> ___________________________
[...]
> Well, it gave me code filled with bugs when I asked it to show me where
> to place the memory barriers in a mutual exclusion lock:
>
> https://i.ibb.co/fYDRNsw/image.png
>
> ___________________________
> ___________________________
>
>
> It put the membars in the wrong places and did not even think about
> atomically acquire and releasing the mutex. I feel like correcting it,
> but why would I do that? Yikes! What a nightmare!
It seemed to know what an acquire barrier is on the SPARC. It said:
>
>
> It put the membars in the wrong places and did not even think about
> atomically acquire and releasing the mutex. I feel like correcting it,
> but why would I do that? Yikes! What a nightmare!
#LoadStore | #LoadLoad
This is right but it missed the MEMBAR instruction as in:
MEMBAR #LoadStore | #LoadLoad
Bonita Montero
Apr 19, 2023, 12:45:24 PM4/19/23
to
and wait for a semaphore if the mutex is already locked.
Chris M. Thomasson
Apr 19, 2023, 3:52:27 PM4/19/23
to
On 4/19/2023 9:47 AM, Bonita Montero wrote:
> Am 19.04.2023 um 04:05 schrieb Chris M. Thomasson:
>> Well, it gave me code filled with bugs when I asked it to show me
>> where to place the memory barriers in a mutual exclusion lock:
>>
>> https://i.ibb.co/fYDRNsw/image.png
>>
>> ___________________________
>> // A mutual exclusion lock.
>> class Mutex
>> {
>> private:
>> // The lock variable.
>> volatile bool lock;
>>
>> public:
>> // Acquires the lock.
>> void Acquire()
>> {
>> // Ensure that the following operations are performed in the
>> correct order.
>> __asm__ volatile("mfence");
>> lock = true;
>> }
[...]
> Am 19.04.2023 um 04:05 schrieb Chris M. Thomasson:
>> Well, it gave me code filled with bugs when I asked it to show me
>> where to place the memory barriers in a mutual exclusion lock:
>>
>> https://i.ibb.co/fYDRNsw/image.png
>>
>> ___________________________
>> // A mutual exclusion lock.
>> class Mutex
>> {
>> private:
>> // The lock variable.
>> volatile bool lock;
>>
>> public:
>> // Acquires the lock.
>> void Acquire()
>> {
>> // Ensure that the following operations are performed in the
>> correct order.
>> __asm__ volatile("mfence");
>> lock = true;
>> }
>> ___________________________
>>
>>
>> It put the membars in the wrong places and did not even think about
>> atomically acquire and releasing the mutex. I feel like correcting it,
>> but why would I do that? Yikes! What a nightmare!
>
> Sorry, that ain't locking. You need to check the before-status
> and wait for a semaphore if the mutex is already locked.
Do not know why Bard generate this code, perhaps because it lifted parts
>>
>>
>> It put the membars in the wrong places and did not even think about
>> atomically acquire and releasing the mutex. I feel like correcting it,
>> but why would I do that? Yikes! What a nightmare!
>
> Sorry, that ain't locking. You need to check the before-status
> and wait for a semaphore if the mutex is already locked.
of it from of the internet? I was amazed at the errors in here. The Bard
needs to be trained. Nobody is paying me to do it. God damn, the errors
are abundant.
Chris M. Thomasson
Apr 19, 2023, 4:01:28 PM4/19/23
to
On 4/19/2023 9:47 AM, Bonita Montero wrote:
> Am 19.04.2023 um 04:05 schrieb Chris M. Thomasson:
>> Well, it gave me code filled with bugs when I asked it to show me
>> where to place the memory barriers in a mutual exclusion lock:
>>
>> https://i.ibb.co/fYDRNsw/image.png
>>
>> ___________________________
[snip bugged bard generated code]
>> Well, it gave me code filled with bugs when I asked it to show me
>> where to place the memory barriers in a mutual exclusion lock:
>>
>> https://i.ibb.co/fYDRNsw/image.png
>>
>> ___________________________
>> ___________________________
>>
>>
>> It put the membars in the wrong places and did not even think about
>> atomically acquire and releasing the mutex. I feel like correcting it,
>> but why would I do that? Yikes! What a nightmare!
>
> Sorry, that ain't locking. You need to check the before-status
> and wait for a semaphore if the mutex is already locked.
Aside from the atomic locking aspect, it placed the memory barriers in
>>
>>
>> It put the membars in the wrong places and did not even think about
>> atomically acquire and releasing the mutex. I feel like correcting it,
>> but why would I do that? Yikes! What a nightmare!
>
> Sorry, that ain't locking. You need to check the before-status
> and wait for a semaphore if the mutex is already locked.
the wrong places. Also, it seems to prefer x86 with its use of the
MFENCE instruction.
Mut...@dastardlyhq.com
Apr 20, 2023, 4:23:42 AM4/20/23
to
rubbish code. They day they start generating efficient working code based on
a simple request we're all out of a job.
Chris M. Thomasson
Apr 20, 2023, 4:04:56 PM4/20/23
to
it put us out of a job. Yikes! ;^o
Chris M. Thomasson
Apr 20, 2023, 4:08:59 PM4/20/23
to
synchronization algorithms. It gets the memory barriers off, amongst
other things... Now, if I were to show it where it went wrong, that
would be teaching it. Why would I want to help it put programmers out of
a job?
Ralf Fassel
Apr 21, 2023, 4:55:28 AM4/21/23
to
* "Chris M. Thomasson" <chris.m.t...@gmail.com>
Can Bard help with coding?
Bard can’t help you with coding just yet. Bard is still learning to
code, and responses about code aren’t officially supported for now.
R'
| So far, it seems to have a hard time creating multi-threaded
| synchronization algorithms. It gets the memory barriers off, amongst
| other things...
Maybe this is why in the FAQ (https://bard.google.com/faq):
| synchronization algorithms. It gets the memory barriers off, amongst
| other things...
Can Bard help with coding?
Bard can’t help you with coding just yet. Bard is still learning to
code, and responses about code aren’t officially supported for now.
R'
Mut...@dastardlyhq.com
Apr 21, 2023, 6:21:59 AM4/21/23
to
On Thu, 20 Apr 2023 13:08:39 -0700
Either way I suspect our profession will go the way of the proverbial buggy
whip maker within the next few decades. Sure, it'll remain as a hobby and in
niche cases but programming as a large scale white collar job will cease to
exist.
"Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:
>On 4/20/2023 1:04 PM, Chris M. Thomasson wrote:
>> On 4/20/2023 1:23 AM, Mut...@dastardlyhq.com wrote:
>>> On Wed, 19 Apr 2023 12:52:08 -0700
>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:
>>>> On 4/19/2023 9:47 AM, Bonita Montero wrote:
>>>>> Sorry, that ain't locking. You need to check the before-status
>>>>> and wait for a semaphore if the mutex is already locked.
>>>>
>>>> Do not know why Bard generate this code, perhaps because it lifted parts
>>>> of it from of the internet? I was amazed at the errors in here. The Bard
>>>> needs to be trained. Nobody is paying me to do it. God damn, the errors
>>>> are abundant.
>>>
>>> I don't know about you but I'm quite glad the language models still
>>> generate
>>> rubbish code. They day they start generating efficient working code
>>> based on
>>> a simple request we're all out of a job.
>>>
>>
>> If I were to teach it how to give a correct answer, that would just help
>> it put us out of a job. Yikes! ;^o
>
>So far, it seems to have a hard time creating multi-threaded
>synchronization algorithms. It gets the memory barriers off, amongst
>other things... Now, if I were to show it where it went wrong, that
>would be teaching it. Why would I want to help it put programmers out of
>a job?
One day - maybe in 10 years, maybe next month - they'll be able to do it.
>On 4/20/2023 1:04 PM, Chris M. Thomasson wrote:
>> On 4/20/2023 1:23 AM, Mut...@dastardlyhq.com wrote:
>>> On Wed, 19 Apr 2023 12:52:08 -0700
>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:
>>>> On 4/19/2023 9:47 AM, Bonita Montero wrote:
>>>>> Sorry, that ain't locking. You need to check the before-status
>>>>> and wait for a semaphore if the mutex is already locked.
>>>>
>>>> Do not know why Bard generate this code, perhaps because it lifted parts
>>>> of it from of the internet? I was amazed at the errors in here. The Bard
>>>> needs to be trained. Nobody is paying me to do it. God damn, the errors
>>>> are abundant.
>>>
>>> I don't know about you but I'm quite glad the language models still
>>> generate
>>> rubbish code. They day they start generating efficient working code
>>> based on
>>> a simple request we're all out of a job.
>>>
>>
>> If I were to teach it how to give a correct answer, that would just help
>> it put us out of a job. Yikes! ;^o
>
>So far, it seems to have a hard time creating multi-threaded
>synchronization algorithms. It gets the memory barriers off, amongst
>other things... Now, if I were to show it where it went wrong, that
>would be teaching it. Why would I want to help it put programmers out of
>a job?
Either way I suspect our profession will go the way of the proverbial buggy
whip maker within the next few decades. Sure, it'll remain as a hobby and in
niche cases but programming as a large scale white collar job will cease to
exist.
Chris M. Thomasson
Apr 22, 2023, 6:28:00 PM4/22/23
to
multi-threaded synchronization is hyper sensitive to bugs... So
sensitive that a memory barrier based race condition might not trigger
until a year under real workloads. Usually right when you say how stable
the system is... ;^)
> Either way I suspect our profession will go the way of the proverbial buggy
> whip maker within the next few decades. Sure, it'll remain as a hobby and in
> niche cases but programming as a large scale white collar job will cease to
> exist.
>
Mut...@dastardlyhq.com
Apr 24, 2023, 4:39:04 AM4/24/23
to
On Sat, 22 Apr 2023 15:27:43 -0700
To be fair most human developers get thread synchronisation wrong at some
point, and I include myself in that list. Its the main reason I don't use
threads unless absolutely required.
I worked at an aerospace manufacturer who shall remain nameless and the
designer of a particular (non safety critical system thankfully) had gone
overboard with threading. Unfortunately a 3rd party message queue library he
used turned out not to be 100% thread safe even though it claimed it was. It
took 6 months to debug because of the unnecessary complexity of his threading
model.
point, and I include myself in that list. Its the main reason I don't use
threads unless absolutely required.
I worked at an aerospace manufacturer who shall remain nameless and the
designer of a particular (non safety critical system thankfully) had gone
overboard with threading. Unfortunately a 3rd party message queue library he
used turned out not to be 100% thread safe even though it claimed it was. It
took 6 months to debug because of the unnecessary complexity of his threading
model.
0 new messages